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(_at_)ietf(_dot_)org] On Behalf Of Alexander
Vainshtein
Sent: Wednesday, January 15, 2014 6:54 AM
To: stbryant(_at_)cisco(_dot_)com
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; tsvwg(_at_)ietf(_dot_)org; Randy
Bush; jnc(_at_)mit(_dot_)edu; lisp(_at_)ietf(_dot_)org
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(_dot_)Vainshtein(_at_)ecitele(_dot_)com
Mobile: 054-9266302
-----Original Message-----
From: mpls [mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Stewart
Bryant
Sent: Wednesday, January 15, 2014 1:31 PM
To: Randy Bush
Cc: gorry(_at_)erg(_dot_)abdn(_dot_)ac(_dot_)uk; mpls(_at_)ietf(_dot_)org;
lisp(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
wes(_at_)mti-systems(_dot_)com; tsvwg(_at_)ietf(_dot_)org;
jnc(_at_)mit(_dot_)edu
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls