MTU and Fragmentation Issues with In-the-Network Tunneling
RFC 4459

[Ballot comment]
A new approach to PMTUD is in the works [13], but it is uncertain
  whether that would fix the problems -- at least not the passive
  monitoring requirements.

A nice document, but about the above:  when the new method
PMTUD works, it looks to the transport like there is a lower
MTU path being encountered.  The mechanism is in-band in
the TCP and SCTP window establishments (and could also
be adapted into the feedback mechanisms of RTP and DCCP,
in the cases where they are able to reduce packet size,
though that has not been discussed).  This is not a blocking comment,
just for information.  One problem is that the PMTUD WG does
not keep moving very well :(

Conclusion: Joe vs draft-savola-mtufrag-network-tunneling-04.txt

-------- Original Message --------
Subject: [Int-area] Re: Conclusion: Joe vs draft-savola-mtufrag-network-tunneling-04.txt
Date: Wed, 05 Oct 2005 11:15:52 -0700
From: Joe Touch
To: Pekka Savola
CC: int-area@ietf.org
References: <42EF5947.5020203@isi.edu>  <42EF739F.6010603@isi.edu>  <42EF77E9.6030302@isi.edu>  <42F09BE1.1040602@isi.edu>  <430CE170.2050700@isi.edu>  <4314DAAF.4060401@isi.edu>  <4329B8C6.6070002@isi.edu>  <433461BC.70400@isi.edu>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Pekka Savola wrote:
> On Fri, 23 Sep 2005, Joe Touch wrote:
>
>>> which changes you'd like to see so I'll just have to ask "send text" and
>>> I'll check it out.
>>
>>
>> IMO, the major doc focus issues are more important and need to be
>> resolved before it would be useful to contribute text, since the latter
>> assumes that such pointwise patches would be productive, and I don't yet
>> see that.
>
> Ok, I think your main argument against the current structure is:
>
>  Documenting existing practice and pointing out the violation as a
>  side-issue isn't acceptable to me because it ends up
>  meaning that this doc is a snapshot of current practice, which I
>  don't think is appropriate for an RFC. IMO, the RFC should make a
>  statement that this is either OK and the spec should be changed or
>  that it's not OK and the implementations should be fixed.
>
> I do not think this is an appropriate as a blocking reason for a
> document

I-D aren't on a default path to RFC that is 'blocked'.

They're on a default path to disappear in 6 months; there needs to be a
*reason* to move to RFC.

There have been cases where there are significant reasons to snapshot
existing practice, so I'm not saying that "no RFCs are just ephemeral
snapshots". But the bar ought to be high, and I think that most of the
key points in this doc, except the fact that people break specs in ways
that we're not intending to endorse, have been made in other docs.
That's why I think the other reasons ought to apply (change the spec or
denounce the practice).

So, yes, this is my position. And yes, it's one person's opinion.

I hope others will consider whether and why this doc should move
forward, not whether it should not, however.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDRBhYE5f5cImnZrsRAk/OAKD7B8ZpKvg+0lvvpNVdkneWKnnOFwCg4Hm9
Hmgv394uoK+C+90kH41NSho=
=iKEI
-----END PGP SIGNATURE-----

_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area