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