Subject: [Tsvwg] WG last call: draft-ietf-tsvwg-udp-guidelines-06

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Apr 2008 17:01:33 +0200

This is announces the WG last call on "UDP Usage Guidelines for 
Application Designers" with the intended status of BCP. Please provide 
any comments no later than the 21st of April.

http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt

Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Mon, 07 Apr 2008 14:16:00 -0300

At 12:01 p.m. 07/04/2008, Magnus Westerlund wrote:

>Application Designers" with the intended status of BCP. Please 
>provide any comments no later than the 21st of April.
>

Some comments:

In section 3.2, the draft states:

    Applications that choose to not adapt their transmit message size
    SHOULD NOT send UDP messages that would result in IP datagrams that
    exceed the effective PMTU.  In the absence of actual knowledge of the
    minimum MTU along the path, the effective PMTU depends upon the IP
    version used for transmission.  It is the smaller of 576 bytes and
    the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for IPv6
    [RFC2460].

This paragraph seems misleading to me. Here you are providing advice 
so that applications avoid fragmentation. But the EMTU_S ("Effective 
MTU for sending") [RFC1122] has nothing to do with avoiding 
fragmentation. The EMTU_S/EMTU_R have to do with the minimum 
reassembly buffer size that is required in IP implementations. 
Therefore, if the advice is meant to avoid fragmentation, you should 
say "It is 68 bytes for IPv4 and 1280 bytes for IPv6".

This requirement (which is a "SHOULD" in the document) would make 
applications such as DNS "non-compliant", as it usually sends 
requests and responses that result in IP datagrams larger than 68 
bytes. Actually, I doubt there are many applications that can meet 
the requirement of sending datagrams of such a small size (the 68 
bytes for IPv4).

I'd also avoid using the term "effective PMTU", and would use the 
term EMTU_S ("Effective MTU for sending") (defined in RFC1122) to 
avoid ambiguities, instead.

Section 3.6:
    If a client/server application executes on a host with more than one
    IP interface, the application SHOULD send any UDP responses in reply
    to arriving UDP datagrams with an IP source address that matches the
    IP destination address of the datagram that carried the request.

You should probably reference RFC1122 here.

Section 3.7:
    Applications SHOULD appropriately respond to ICMP messages generated
    in response to transmitted traffic.  A correct response often
    requires context, such as local state about communication instances
    to each destination, that although readily available in connection-
    oriented transport protocols is not always maintained by UDP-based
    applications.

I'd probably replace the first instance of "respond" with "process". 
i.e., s/respond to/process/

My two cents.

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Lars Eggert <[email-masked]>
Date: Mon, 14 Apr 2008 16:13:58 -0700

Hi,

thanks for the comments!

> reassembly buffer size that is required in IP implementations.

I don't agree. Section 3.3.3 in RFC1122, where EMTU_S is defined, is  
all about sending and doesn't discuss reassembly at all. (Section  
3.3.2 defines EMTU_R, which is about reassembly.)

> say "It is 68 bytes for IPv4 and 1280 bytes for IPv6".

I agree that according to the RFCs, 68 bytes is the limit that is  
guaranteed to be forwarded without fragmentation. But even RFC1122  
admits that that is too small in practice, and says in Section 3.3.3:

              Since nearly all networks in the Internet currently
              support an MTU of 576 or greater, we strongly recommend
              the use of 576 for datagrams sent to non-local networks.

Our document merely follows this advice.

(And the goal isn't to completely prevent all fragmentation; the goal  
is to suggest that applications should really try to avoid operating  
under persistent fragmentation. Maybe that doesn't come out in the  
draft?)

> the requirement of sending datagrams of such a small size (the 68  

Not an issue if the limit isn't 68 bytes (which I don't think it  
should be.)

> avoid ambiguities, instead.

I'd be fine with referring to EMTU_S.

> You should probably reference RFC1122 here.

Are you suggesting to point to Section 4.1.3.5?

> i.e., s/respond to/process/

I'm fine with this change.

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Apr 2008 05:40:07 -0300

>3.3.2 defines EMTU_R, which is about reassembly.)

My point is that you're using different protocol parameters for the 
same thing. You cite IPv6's minimum MTU (1280), but cite IPv4's 
minimum reassembly buffer size (576) for the same purpose (rather 
than the minimum IPv4 MTU). (And this is what looks confusing to me)

By sending IPv6 datagrams that are equal to or smaller than 1280, you 
can be assured that fragmentation won't be needed (well, at least for 
this particular layer of IP). However, by sending IPv4 packets of 576 
bytes, you cannot guarantee this.

(As a side note, my take is that the reason for using 576 in RFC 1122 
and not, say, 800, 1000 (or whatever), is that you are not assured 
that the receiving host will be able to receive datagrams larger than 
576 bytes.)

>under persistent fragmentation. Maybe that doesn't come out in the

It didn't to me (from that section), at least. The impression I got 
was that you were providing advice on packets sizes that would avoid 
fragmentation (1280 would do for v6... but 576 wouldn't for v4... and 
hence the confussion)

>Are you suggesting to point to Section 4.1.3.5?

Yes. (Sorry for not providing a pointer to the specific section)

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Apr 2008 09:19:33 -0700

Hi,

On 2008-4-16, at 1:40, ext Fernando Gont wrote:
> By sending IPv6 datagrams that are equal to or smaller than 1280,  
> you can be assured that fragmentation won't be needed (well, at  
> least for this particular layer of IP). However, by sending IPv4  
> packets of 576 bytes, you cannot guarantee this.

I agree with you that the theoretically safe value is 68 bytes. But  
even RFC1122 has suggested that this is impractical (see the quote  
below) and that 576 bytes should be used, and all our experience since  
RFC1122 was published suggests that 576 bytes is an appropriate  
practical value.

(And yes, the rationale behind the suggested value may be different  
for IPv4 and IPv6, but I doubt that an application designer reading  
these guidelines will care much about that.)

> fragmentation (1280 would do for v6... but 576 wouldn't for v4...  
> and hence the confussion)

A limit of 576 bytes will avoid fragmentation for IPv4 in all  
realistic cases. That's been the case when RFC1122 was published, and  
experience suggests that this hasn't changed. (If anything, larger  
values may have become safe in practice in the meantime, but since we  
don't have data, I'd be hesitant to recommend something larger than  
576 bytes.)

> Yes. (Sorry for not providing a pointer to the specific section)

Reference added.

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Apr 2008 13:58:55 -0300

>RFC1122 was published suggests that 576 bytes is an appropriate

I'm not saying that it is not. I'm just saying that unless this point 
is made clear, the text might mislead the reader into thinking the 
choice of 576 bytes will avoid fragmentation, when it won't. 
(Particularly when there have been a number of i-ds in the past that 
simply (and mistakenly) assumed the IPv4 MTU to be 576, rather than 68)

>these guidelines will care much about that.)

My take is that whoever reads this doc must be knowledgeable in 
TCP/IP. I cannot imagine, e.g., a database programmer thinking about 
fragmentation issues and the like (he probably would not even know 
these issues exist).

>don't have data, I'd be hesitant to recommend something larger than

There are realistic cases which involve MTUs lower than 576 bytes. A 
number of radio devices come to my mind.

(As a side note, when working on the ICMP attacks draft, I was 
thinking about enforcing a lower limit of 576 bytes for the PMTU. But 
a number of different developers pointed out what I said above: there 
are still a number of devices that use small MTUs. The only safe 
value to enforce as a lower limit is 296 bytes or the like. That's 
the limit OpenBSD and IIRC Linux enforce)

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Apr 2008 11:05:32 -0700

Hi,

On 2008-4-16, at 9:58, ext Fernando Gont wrote:
> I'm not saying that it is not. I'm just saying that unless this  
> point is made clear, the text might mislead the reader into thinking  
> the choice of 576 bytes will avoid fragmentation, when it won't.

We're going in circles. For all practically relevant cases, it *will*  
avoid fragmentation. RFC1122 already recommended to use 576 bytes  
(unless the MTU of the directly-connected interface is lower). This  
document merely repeats this advice.

I have seen no data that would suggest that 576 bytes has become too  
large to recommend. If anything, some folks have argued that is may be  
to small.

> My take is that whoever reads this doc must be knowledgeable in TCP/ 
> IP. I cannot imagine, e.g., a database programmer thinking about  

The document is meant for folks who want to use UDP. So they will have  
some networking knowledge. The document means to give them practically  
useful guidelines together with pointers to where folks can go to read  
more detail. In this case, it says what message sizes application  
designers can asume to avoid fragmentation, and it refers to RFC1122  
so that folks can read up on the details.

> number of radio devices come to my mind.

OK, I'll bite: which radio devices?

Note that the document actually recommends that applications do PMTUD  
discovery. If they do, there is no issue. Further, note that the  
guideline says "the smaller of 576 bytes and the first-hop MTU", so  
that in cases where the first-hop happens to be such a radio device, a  
value less than 576 bytes is chosen. So the only case where the  
current guideline would result in a too-large message is where such a  
radio link is not the first hop.

> thinking about enforcing a lower limit of 576 bytes for the PMTU.  
> But a number of different developers pointed out what I said above:  
> there are still a number of devices that use small MTUs. The only  
> safe value to enforce as a lower limit is 296 bytes or the like.  
> That's the limit OpenBSD and IIRC Linux enforce)

The 296 bytes value comes from what some SLIP implementations used as  
the default. My understanding is that current SLIP implementations  
have increased this default. Even RFC1144 recommended that SLIP  
implementations be prepared to accept messages of 1006 bytes.

I'd like the rest of the WG to chime in on this issue; I'd like to  
find out if Fernando or I are on the rough side of the consensus.

Lars

---

From: David Borman <[email-masked]>
Date: Wed, 16 Apr 2008 15:52:35 -0400

So, my $.02 is that 576 is fine, and the wording is fine.  The  
document doesn't just say 576, it first says the actual PMTU, and in  
the absence of that, the lower of 576 and the first-hop MTU.  Anyone  
who gets confused by that into thinking that 576 guarantees that  
packets won't be fragmented just isn't paying attention.  We have to  
assume at least some level of competence on the part of the reader,  
and I don't think this issue goes above that threshold.

			-David Borman

On Apr 16, 2008, at 2:05 PM, Lars Eggert wrote:

>> point is made clear, the text might mislead the reader into  
>> thinking the choice of 576 bytes will avoid fragmentation, when it  
>> won't.
>
> We're going in circles. For all practically relevant cases, it  
> *will* avoid fragmentation. RFC1122 already recommended to use 576  
> bytes (unless the MTU of the directly-connected interface is lower).  
> This document merely repeats this advice.
>
> large to recommend. If anything, some folks have argued that is may  
> be to small.
>
> The document is meant for folks who want to use UDP. So they will  
> have some networking knowledge. The document means to give them  
> practically useful guidelines together with pointers to where folks  
> can go to read more detail. In this case, it says what message sizes  
> application designers can asume to avoid fragmentation, and it  
> refers to RFC1122 so that folks can read up on the details.
>
>> There are realistic cases which involve MTUs lower than 576 bytes.  
>> A number of radio devices come to my mind.
>
> Note that the document actually recommends that applications do  
> PMTUD discovery. If they do, there is no issue. Further, note that  
> the guideline says "the smaller of 576 bytes and the first-hop MTU",  
> so that in cases where the first-hop happens to be such a radio  
> device, a value less than 576 bytes is chosen. So the only case  
> where the current guideline would result in a too-large message is  
> where such a radio link is not the first hop.
>
> The 296 bytes value comes from what some SLIP implementations used  
> as the default. My understanding is that current SLIP  
> implementations have increased this default. Even RFC1144  
> recommended that SLIP implementations be prepared to accept messages  
> of 1006 bytes.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Apr 2008 02:47:58 -0300

At 03:05 p.m. 16/04/2008, Lars Eggert wrote:

Meta-note: My comments were meany to be constructive, as were 
certainly not a show-stopper. I think it they were pretty easy to 
address. Whether you decide to address them or not is not a concern 
to me (I'm not "pushing" any changes).

That said, my last set of comments are inline...

>OK, I'll bite: which radio devices?

e.g., packet radio. FWIW, I think that's what made OpenBSD and Linux 
adopt the 296-byte limit. IIRC, Linux's David Miller and maybe 
OpenBSD's {Frantzen, Friedl} were the people that had provided the 
insights on that limit.

>radio link is not the first hop.

Agreed. And probably in most packet radio scenarios, the first-hop 
will have that small MTU, so it will have precedence (i.e., it will 
be smaller than) the 576 value.

My take was that the whole thing cold have been clarified with a 
short comment on why for the v6 case it is the minimum MTU that is 
chosen, while for IPv4 it is the minimum reassembly buffer size. That 
said, that's my $ 0.02. I have no personal interest in this being 
addressed or not. My comment was meant to what I think would have 
improved the doc.

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Apr 2008 02:54:11 -0300

>and I don't think this issue goes above that threshold.

I had spotted that confusion in the past in some other wg's document 
which were supposed to be close to publication as RFC (that's why I 
thought it might be good to include a short sentence that makes this 
point clear). So I'm not sure how I should read your comment.

Kind regards,

---

From: David Borman <[email-masked]>
Date: Thu, 17 Apr 2008 09:49:54 -0400

I think the current text covers the topic, I don't see any need to add  
anything further.
			-David

---

From: Jukka Manner <[email-masked]>
Date: Fri, 18 Apr 2008 08:10:46 +0300

I also agree with this statement, well said.

Jukka

David Borman wrote:
> So, my $.02 is that 576 is fine, and the wording is fine.  The document 
> doesn't just say 576, it first says the actual PMTU, and in the absence 
> of that, the lower of 576 and the first-hop MTU.  Anyone who gets 
> confused by that into thinking that 576 guarantees that packets won't be 
> fragmented just isn't paying attention.  We have to assume at least some 
> level of competence on the part of the reader, and I don't think this 
> issue goes above that threshold.
> 
>             -David Borman
>

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 25 Apr 2008 09:59:24 +0300 (EEST)

I have read the UDP Guidelines and it is a good document, as Rob and Pasi 
already said. A couple of small comments:

- Related to Rob's comments, the document could be extended to cover also 
  protocols that run directly over IP. The introduction could highlight 
  this, but then say that what the document says about UDP applies also 
  to other like protocols. So, no need to write long additional text, 
  just note that there are, and will be, also protocols that do are not 
  run over UDP.

- The introduction talks about multicast, but then leaves the topic quite 
  open. At least one subsection could be usefull to discuss the topic a 
  bit furhter.

- p.7, 1st line: s/"chose not to"/"may choose not to"/

- p.9, 2nd bullet, 2nd para, 1st line "This can be [the] case,"

- I was going to throw the same comment than Pasi already did regarding 
  the NAT/FW keep-alive and mobile, battery-operated devices.

- Should POSIX really be a Normative ref? Probably informative is enough.

br,
Jukka

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Apr 2008 15:57:16 +0200

Hi,

This last call has ended and I request the authors to take care of the 
comments.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Apr 2008 13:30:15 +0300

On 2008-4-25, at 16:57, ext Magnus Westerlund wrote:
> This last call has ended and I request the authors to take care of  
> the comments.

Thanks for the extremely useful comments during WGLC! Gorry and me  
will work on incorporating them into an update, but it'll likely take  
a few weeks.

Lars