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:tsvwg-bounces@xxxxxxxx] On Behalf Of Alexander Vainshtein > Sent: Wednesday, January 15, 2014 6:54 AM > To: stbryant@xxxxxxxxx > Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; ietf@xxxxxxxx; tsvwg@xxxxxxxx; Randy > Bush; jnc@xxxxxxx; lisp@xxxxxxxx > 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: Alexander.Vainshtein@xxxxxxxxxxx > Mobile: 054-9266302 > > > -----Original Message----- > > From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of Stewart Bryant > > Sent: Wednesday, January 15, 2014 1:31 PM > > To: Randy Bush > > Cc: gorry@xxxxxxxxxxxxxx; mpls@xxxxxxxx; lisp@xxxxxxxx; ietf@xxxxxxxx; > > wes@xxxxxxxxxxxxxxx; tsvwg@xxxxxxxx; jnc@xxxxxxx > > 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 > > mpls@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/mpls