Re: [nvo3] Dataplane requirements draft - section 3.5 - path MTU text

["Black, David" <[e-mail]>]

Marc, More inline ... Thanks, --David

> -----Original Message-----
> From: LASSERRE, MARC (MARC) [mailto:[e-mail]]
> Sent: Friday, May 23, 2014 3:49 AM
> To: Black, David; [e-mail]
> Subject: RE: Dataplane requirements draft - section 3.5 - path MTU text
> 
> Dave,
> 
> See my comments below.
> 
> Thanks,
> Marc
> 
> > -----Original Message-----
> > From: Black, David [mailto:[e-mail]]
> > Sent: Thursday, May 22, 2014 8:20 PM
> > To: LASSERRE, MARC (MARC); [e-mail]
> > Subject: RE: Dataplane requirements draft - section 3.5 -
> > path MTU text
> >
> > > Concerning your last question, the following sentence in 3.5 indicates
> > > that MTU discovery is the TS's responsibility:
> > >
> > > "The interface MTU as seen by a Tenant System SHOULD be adjusted such
> > > that no fragmentation is needed. This can be achieved by configuration
> > > or be discovered dynamically."
> >
> > In that case, the use of "interface MTU" seems off, as I
> > interpret that term as the link MTU presented by the network
> > interface to the TS (that interface may be virtual or
> > physical.  That interpretation would not be correct for a
> > Tenant System implementation of RFC 4821 (PL PMTUD) that's
> > integrated with a transport protocol such as TCP because the
> > result has no effect on interface MTU (if the path MTU is
> > smaller than the interface MTU, TCP sends smaller packets).
> 
> Interface MTU is used as the link MTU in this sentence. But I do not see why
> it is not correct if RFC4821 is used.
> The path MTU discovered via PLPMTUD is dependent upon the link MTU used...

[*] The TCP implementation cannot adjust the interface or link MTU; TCP has
to take that MTU as a given, as noted above, and as stated in the framework
draft.

> > If RFC 4821 is implemented to deal with this path MTU
> > discovery requirememnt, where would that implementation be located?
> 
> It is the TS's responsability. But in the case where RFC4821 is not supported,
> The NVE may have to fragment/reassemble IP packets as implied in the 2nd
> option described in this paragraph.

The concern is that I don't understand how or why the nvo3 dataplane
requirements draft should be putting requirements on Tenant System
transport protocol implementations (e.g., TCP), when those implementations
(e.g., in a virtual machine) are outside the scope of nvo3 dataplanes.

In contrast, the framework draft text on path MTU is ok, because it
describes what those implementations could do without using either
"SHOULD" or "MUST".

As opposed to generating yet more angle brackets, I'll think about this
and try to send a new message with some better proposed text later today,
but the current text now appears to be actually wrong courtesy of the
problem noted above at [*].
 
> >
> > Thanks,
> > --David
> >
> > > -----Original Message-----
> > > From: LASSERRE, MARC (MARC)
> > [mailto:[e-mail]]
> > > Sent: Thursday, May 22, 2014 4:12 AM
> > > To: Black, David; [e-mail]
> > > Subject: RE: Dataplane requirements draft - section 3.5 - path MTU
> > > text
> > >
> > > Hi David,
> > >
> > > Thanks for the suggested text. It will be incorporated in
> > the next revision.
> > >
> > > Concerning your last question, the following sentence in
> > 3.5 indicates
> > > that MTU discovery is the TS's responsability:
> > >
> > > "The interface MTU as seen by a Tenant System SHOULD be
> > adjusted such
> > > that no fragmentation is needed. This can be achieved by
> > configuration
> > > or be discovered dynamically."
> > >
> > > Marc
> > >
> > > > -----Original Message-----
> > > > From: nvo3 [mailto:[e-mail]] On Behalf Of
> > Black, David
> > > > Sent: Wednesday, May 21, 2014 6:14 PM
> > > > To: [e-mail]
> > > > Subject: [nvo3] Dataplane requirements draft - section 3.5 - path
> > > > MTU text
> > > >
> > > > Turning to the dataplane requirements draft, here's proposed
> > > > elaboration text for the path MTU material in section 3.5
> > (no change
> > > > to the second and third bullet items - they're included for
> > > > completeness):
> > > >
> > > > OLD
> > > >        Either of the following options MUST be supported:
> > > >
> > > >           o Classical ICMP-based MTU Path Discovery
> > [RFC1191] [RFC1981] or
> > > >             Extended MTU Path Discovery techniques such
> > as defined in
> > > >             [RFC4821]
> > > >
> > > >           o Segmentation and reassembly support from the
> > overlay layer
> > > >             operations without relying on the Tenant
> > Systems to know about
> > > >             the end-to-end MTU
> > > >
> > > >           o The underlay network MAY be designed in such
> > a way that the MTU
> > > >             can accommodate the extra tunnel overhead.
> > > > NEW
> > > >        At least one of the following options MUST be supported:
> > > >
> > > >           o Classical ICMP-based MTU Path Discovery
> > [RFC1191] [RFC1981] or
> > > >             Extended MTU Path Discovery techniques such
> > as defined in
> > > >             [RFC4821].  Both techniques are based on use
> > of probe packets.
> > > >             Classical MTU Path Discovery requires ICMP
> > responses from
> > > >             the underlay network.  Extended MTU Path
> > Discovery requires
> > > >             detection of probe packet loss at the
> > receiver and means to
> > > >             communicate that loss to the sender.
> > > >
> > > >           o Segmentation and reassembly support from the
> > overlay layer
> > > >             operations without relying on the Tenant
> > Systems to know about
> > > >             the end-to-end MTU
> > > >
> > > >           o The underlay network MAY be designed in such
> > a way that the MTU
> > > >             can accommodate the extra tunnel overhead.
> > > >
> > > > ------------------------------
> > > >
> > > > There's an additional question - what does that initial
> > "MUST" ("At
> > > > least one of the following options MUST be
> > > > supported:") apply to??
> > > >
> > > > The framework draft text on this topic describes Tenant Systems
> > > > using MTU discovery techniques, whereas some of the options above
> > > > apply to the nvo3 dataplane (e.g., overlay segmentation and
> > > > reassembly could reside in NVEs).
> > > >
> > > >
> > > > Thanks,
> > > > --David
> > > > ----------------------------------------------------
> > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South
> > > > St., Hopkinton, MA  01748
> > > > [phone]             FAX: [phone]
> > > > [e-mail]        Mobile: [phone]
> > > > ----------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > nvo3 mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/nvo3
> > > >
> >