Hi Carlos, Thanks for the reference below. So, this means the answer is "it depends" on the packetization layer above UDP, but do you know if it is common for applications running over UDP to pay attention to the PMTU and adjust its packetization size accordingly? Are there known "problem protocols" that don't do this? (e.g. RFC 1191 that you reference mentions NFS, but this may no longer be true of newer implementations?).
Thanks, Larry From: "Carlos Pignataro (cpignata)" <[email protected]<mailto:[email protected]>> Date: Saturday, April 11, 2015 5:55 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: Anoop Ghanwani <[email protected]<mailto:[email protected]>>, Erik Nordmark <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Lucy yong <[email protected]<mailto:[email protected]>>, Lizhong Jin <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Encapsulation considerations On Apr 10, 2015, at 3:49 PM, Larry Kreeger (kreeger) <[email protected]<mailto:[email protected]>> wrote: I thought Path MTU discovery was used to set the MSS in the TCP stack. I just wasn't sure if it worked the same way for UDP. Since, as you know, UDP has no MSS and no connection, the packetization size state is maintained by the application on top of UDP, or suffer IP-level fragmentation. See e.g, first para of https://tools.ietf.org/html/rfc1191#section-6.1 Thanks, ― Carlos. - Larry From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Friday, April 10, 2015 12:10 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: Lizhong Jin <[email protected]<mailto:[email protected]>>, Lucy yong <[email protected]<mailto:[email protected]>>, Erik Nordmark <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Encapsulation considerations Even for TCP it depends on what the MSS is. Anoop On Fri, Apr 10, 2015 at 11:55 AM, Larry Kreeger (kreeger) <[email protected]<mailto:[email protected]>> wrote: On 4/9/15 7:22 PM, "Lizhong Jin" <[email protected]<mailto:[email protected]>> wrote: >>-----Original Message----- >>From: Lucy yong [mailto:[email protected]<mailto:[email protected]>] >>Sent: 2015年4月9日 22:28 >>To: Lizhong Jin; 'Erik Nordmark'; [email protected]<mailto:[email protected]> >>Subject: RE: [nvo3] Encapsulation considerations >>Lizhong, >>[snip] >> [Lizhong] If the NVE and tenant is integrated into one device, then >>the issue >>could be solved by implementation. Because tenant know the entropy value >>of >>the first segment, and use the same value to the subsequent segment. So >>different implementation model could provide different entropy value. Or >>do we >>need other mechanism to mitigate this issue, e.g., fragment on NVE in >>draft-herbert-gue-fragmentation. >>[Lucy] IMO: NVO3 solution SHOULD avoid packet fragmentation. >>Draft-herbert-gue-fragmentation provides an option for a GUE application >>to do >>fragmentation but does not require doing it. GUE application decides if >>the >>fragmentation is needed or not. We should not separate two. >[Lizhong] fragmentation could not be avoided, because we are unable to >prevent >the tenant from fragmentation. This is the factor which makes the hashing >based >load balancing unoptimized. I'm not very familiar with host stacks. Do they actually fragment at the IP layer, or is it done at the transport layer before adding the IP header? I'm sure TCP must break the segments up before IP would fragment, but I'm not sure about UDP. - Larry _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
