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

From: "Black, David" <[email-masked]>
Date: Wed, 21 May 2014 12:13:56 -0400

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 22 May 2014 08:11:51 +0000

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:[email-masked]] On Behalf Of Black, David
> Sent: Wednesday, May 21, 2014 6:14 PM
> To: [email-masked]
> 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
> 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
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 May 2014 09:45:38 -0700

Hi, all,

Why not just have the Tenant Systems that act as end hosts just follow 
RFCs 1122 and 1123?

I.e,:

----
Tenant Systems that source or sink IP traffic are Internet hosts, and 
thus are (already) required to be compliant with RFC 1122 and 1123.

Tenant Systems that forward IP traffic are Internet routers, and thus 
are (already) required to be compliant with RFC 1812 (etc.).
---

(that goes for a lot of other stuff in this doc - if properly mapped to 
existing Internet components, there is no need for either new mechanism 
or even new requirements).

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 22 May 2014 14:19:48 -0400

> 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).

If RFC 4821 is implemented to deal with this path MTU discovery requirememnt,
where would that implementation be located?

Thanks,
--David

> From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
> Sent: Thursday, May 22, 2014 4:12 AM
> To: Black, David; [email-masked]
> Subject: RE: Dataplane requirements draft - section 3.5 - path MTU text
> 
> Hi David,
> 
> 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
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 May 2014 11:28:08 -0700

On 5/22/2014 11:19 AM, Black, David wrote:
> be virtual or physical.

Right - and that's typically configurable, but it represents only the 
property of the interface and its L2 subnet, not a path (PMTUD and 
PLMTUD discover path properties).

Joe

> That interpretation would not be correct for a Tenant

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Fri, 23 May 2014 07:49:04 +0000

Dave,

See my comments below.

Thanks,
Marc 

> From: Black, David [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2014 8:20 PM
> To: LASSERRE, MARC (MARC); [email-masked]
> > 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...
What wording would you suggest?

> 
> 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.

> > From: LASSERRE, MARC (MARC) 
> [mailto:[email-masked]]
> > 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
> > 
> > > Subject: [nvo3] Dataplane requirements draft - section 3.5 - path 
> > > MTU text
> > >
> > > 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
> "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

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Fri, 23 May 2014 08:10:46 +0000

Hi Joe,

See my comments below.

Thanks,
Marc 

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Thursday, May 22, 2014 6:46 PM
> To: LASSERRE, MARC (MARC); Black, David; [email-masked]
> Subject: Re: [nvo3] Dataplane requirements draft - section 
> 3.5 - path MTU text
> 
> Hi, all,
> 
> Why not just have the Tenant Systems that act as end hosts 
> just follow RFCs 1122 and 1123?

This is the expectation for IP tenant systems.

L2/non-IP tenant systems are also supported.

> 
> I.e,:
> 
> ----
> Tenant Systems that source or sink IP traffic are Internet 
> hosts, and thus are (already) required to be compliant with 
> RFC 1122 and 1123.
> 
> Tenant Systems that forward IP traffic are Internet routers, 
> and thus are (already) required to be compliant with RFC 1812 (etc.).
> ---
> 
> (that goes for a lot of other stuff in this doc - if properly 
> mapped to existing Internet components, there is no need for 
> either new mechanism or even new requirements).

True. A lot of existing mechanisms can and should be re-used. 
The intent of this draft is to describe a list of (not necessarily new) requirements for nvo3 solutions to address.

> 3.5 indicates that MTU discovery is the TS's responsability:
> >
> adjusted such that no fragmentation is needed. This can be 
> achieved by configuration or be discovered dynamically."
> >
> > Marc
> >
> >> Subject: [nvo3] Dataplane requirements draft - section 3.5 
> - path MTU 
> >> text
> >>
> >>              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
> >>              detection of probe packet loss at the 
> receiver and means 
> >> to
> >>              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
> 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

---

From: "Black, David" <[email-masked]>
Date: Fri, 23 May 2014 09:20:31 -0400

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

> Sent: Friday, May 23, 2014 3:49 AM
> > > Concerning your last question, the following sentence in 3.5 indicates
> > > "The interface MTU as seen by a Tenant System SHOULD be adjusted such
> > > that no fragmentation is needed. This can be achieved by configuration

[*] 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.

> 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 [*].
 
> > Systems to know about
> > a way that the MTU
> > receiver and means to
> > Systems to know about
> > a way that the MTU