Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp)

From: "Black, David" <[email-masked]>
Date: Sun, 19 Jan 2014 22:30:08 -0500

Sasha,

> But I would like to understand whether this protocol can really result in
> reasonable distribution of traffic. "Reasonable" means that (a) there is
> sufficient entropy and (b) that the order in specific micro-flows is
> preserved. The draft skips this issue (unless you consider a recommendation to
> use a fixed  randomly selected source port value if the tunnel does not need
> ECMP a valid answer) .

Well, there's a bit more in the draft than just a "randomly selected" value,
as the ability to use ECMP on these tunnels is rather important (text quoted
is from Section 3 in the draft):

   The ingress device SHOULD set
   the UDP source port based on flow invariant fields from the payload
   header, otherwise it should be set to a randomly selected constant
   value, e.g. zero, to avoid packet flow reordering.  How a tunnel
   ingress generates entropy from the payload is outside the scope of
   this document.

I suppose that more discussion and examples of "flow invariant fields"
would be useful, although an attempt at a comprehensive listing would be
pointless, IMHO.  An important situation is one where the tunnel ingress
"knows" (because the network operator actually does know) what the protocol
stack(s) is/are for the encapsulated traffic (e.g., HTTP/TCP/IP/GRE/IP) and
hence can find the flow-invariant fields that it wants to use for that
(those) specific stack(s).

With good selection of flow-invariant fields wrt traffic mix, good
distribution is possible.

Thanks,
--David

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: Wednesday, January 15, 2014 6:54 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; Randy
> Bush; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-in-
> udp draft (was: RE: Milestones changed for tsvwg WG))
> 
> Stewart, and all,
> I fully agree that UDP checksums is not a real-life issue with the protocol in
> question. They could probably help to check corrupted packets if corruption
> happens when a packet passes thru a router (i.e. when the ingress data link
> FCS has already been terminated and the egress data link FCS has not been
> generated yet). But this is hopefully rare - and since MPLS does not care
> about it, why should the MPLS encapsulator care?
> 
> I also do not think that congestion control is a serious issue for this
> protocol, not in the least because the primary purpose of this protocol is
> ECMP.
> 
> But I would like to understand whether this protocol can really result in
> reasonable distribution of traffic. "Reasonable" means that (a) there is
> sufficient entropy and (b) that the order in specific micro-flows is
> preserved. The draft skips this issue (unless you consider a recommendation to
> use a fixed  randomly selected source port value if the tunnel does not need
> ECMP a valid answer) .
> 
> Any ideas as to how reasonable distribution of traffic  can be achieved with
> this protocol?
> 
> Regards,
>        Sasha
> Email: [email-masked]
> Mobile: 054-9266302
> 
> > -----Original Message-----
> > From: mpls [mailto:[email-masked]] On Behalf Of Stewart Bryant
> > Sent: Wednesday, January 15, 2014 1:31 PM
> > To: Randy Bush
> > Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked]
> > Subject: Re: [mpls] [tsvwg] OT (was Re: draft-ietf-mpls-in-udp was RE: gre-
> in-
> > udp draft (was: RE: Milestones changed for tsvwg WG))
> >
> > On 15/01/2014 11:08, Randy Bush wrote:
> > > [ you insist on cc:ing me, so you get to endure my opinions ]
> > >
> > >> it seems that there are no valid statistics for the current Internet
> > >> to sustain your case.
> > > as we discussed privately, there seem to be no real measurements to
> > > sustain any case.  this is all conjecturbation.
> > >
> > > what i do not understand is why, given the lack of solid evidence that
> > > we are in a safe space, you and others are not willing to spend a few
> > > euro cents to have a reasonable level of assurance at this layer.
> > >
> > > randy
> > Randy,
> >
> > It is not a few cents, it is likely the re-engineering of a lot of silicon.
> >
> > The reason that UDP is of interest is that the on path silicon knows how to
> > process it, for example it knows how to to ECMP it.
> >
> > The reason that the UDP c/s is a problem for a tunneler is that it needs to
> > have access to the whole pkt to calculate the c/s, but as you know the
> silicon
> > optimised that access away a long time ago.
> >
> > The alternative would be UDP-lite, but the ability of on path silicon to
> process
> > that as competently and as completely as it processes UDP is by no means
> > clear.
> >
> > - Stewart
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 Jan 2014 12:25:28 -0500

Alex,

> In the case of GRE-in-UDP the text goes into more detail, but, IMHO and FWIW,
> these details are not sufficient. AFAIK , the GRE encapsulators in most cases
> follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 2784
> does not leave any place for meaningful "flow invariant fields" (unless you
> count the protocol type as such).  This means that the head-end of the UDP
> tunnel has to look beyond the IP and GRE headers of the packet to be
> encapsulated for these fields - and this is something that, to the best of my
> understanding, GRE tries to prevent.

My understanding of the intent of the GRE in UDP draft is that the encapsulator
really has to look beyond the GRE header to set the UDP source port in order to
get load balancing.  E.g., for MPLS/GRE/UDP, the ECMP hash for MPLS would be
the basis for setting the UDP source port in a fashion analogous to Eric's message.
This requires encapsulators that can do that, and do analogous things for other
protocol stacks above GRE (e.g., those that do not use MPLS).

Thanks,
--David

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: Monday, January 20, 2014 12:45 AM
> To: Black, David; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Randy Bush; [email-masked]
> Subject: RE: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT
> (was Re: draft-ietf-mpls-in-udp)
> 
> David,
> Lots of thanks for a detailed response.
> 
> My original question dealt with the MPLS-in-UDP draft, where the relevant text
> was quite brief:
> 
> <quote>
>             Source Port of UDP
> 
>                 This field contains a 16-bit entropy value that is
>                 generated by the ingress PE router. What algorithm is
>                 actually used by the ingress PE router to generate an
>                 entropy value is outside the scope of this doc. In the
>                 case where the flow does not need entropy, this field
>                 SHOULD be set to a randomly selected constant value to
>                 avoid packet reordering.
> <end quote>
> 
> The answer given by Eric Rosen in http://www.ietf.org/mail-
> archive/web/mpls/current/msg11277.html (use the hash of the label stack of the
> packet to be encapsulated ) resolves, IMO, this issue because the head-end of
> the UDP tunnel (the encapsulator) looks at the label stack of the packet to be
> encapsulated in any case. Of course other methods are not precluded, but there
> is at least one method that is both reasonably simple and meaningful,
> especially because it is possible to add entropy to the label stack (RFC
> 6790).
> 
> In the case of GRE-in-UDP the text goes into more detail, but, IMHO and FWIW,
> these details are not sufficient. AFAIK , the GRE encapsulators in most cases
> follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 2784
> does not leave any place for meaningful "flow invariant fields" (unless you
> count the prtotocol type as such).  This means that the head-end of the UDP
> tunnel has to look beyond the IP and GRE headers of the packet to be
> encapsulated for these fields - and this is something that, to the best of my
> understanding, GRE tries to prevent.
> 
> My 2c,
>      Sasha
> ________________________________________
> From: Black, David <[email-masked]>
> Sent: Monday, January 20, 2014 5:30 AM
> To: Alexander Vainshtein; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; Randy Bush; [email-masked];
> Black, David
> Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was
> Re: draft-ietf-mpls-in-udp)
> 
> Sasha,
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 20 Jan 2014 05:44:33 +0000

David,

My original question dealt with the MPLS-in-UDP draft, where the relevant text was quite brief:

<quote>
            Source Port of UDP 

The answer given by Eric Rosen in http://www.ietf.org/mail-archive/web/mpls/current/msg11277.html (use the hash of the label stack of the packet to be encapsulated ) resolves, IMO, this issue because the head-end of the UDP tunnel (the encapsulator) looks at the label stack of the packet to be encapsulated in any case. Of course other methods are not precluded, but there is at least one method that is both reasonably simple and meaningful, especially because it is possible to add entropy to the label stack (RFC 6790).

In the case of GRE-in-UDP the text goes into more detail, but, IMHO and FWIW, these details are not sufficient. AFAIK , the GRE encapsulators in most cases follows RFC 2784 and not RFC 1701. The reduced GRE header adopted RFC 2784 does not leave any place for meaningful "flow invariant fields" (unless you count the prtotocol type as such).  This means that the head-end of the UDP tunnel has to look beyond the IP and GRE headers of the packet to be encapsulated for these fields - and this is something that, to the best of my understanding, GRE tries to prevent.

My 2c,
     Sasha
________________________________________
From: Black, David <[email-masked]>
Sent: Monday, January 20, 2014 5:30 AM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Randy Bush; [email-masked]; Black, David
Subject: GRE in UDP - traffic distribution ( was RE: [tsvwg] [mpls] OT (was Re: draft-ietf-mpls-in-udp)

Sasha,

Thanks,
--David