Joe,
Following up my email to you in May quoted further down, you made me
realize that RFC6040 did not
address what to do with ECN during fragmentation and reassembly. So I've
added the following to
my local copy of draft-ietf-tsvwg-rfc6040-update-shim (to be posted later
today), which recently
went through TSVWG last call, and will imminently be last called on
various int-area lists, I
believe.
These are quite significant updates to outer fragment processing at the
tunnel egress. But, given
something has to be said, I can't think of a better way (see the original
quoted email about why
the logical OR of the ECN codepoints as defined in RFC3168 is no longer
sufficient - and it's no
simpler anyway).
5. ECN Propagation and Fragmentation/Reassembly
The following requirements update RFC6040, which omitted handling of
the ECN field during fragmentation or reassembly. These changes
might alter how many ECN-marked packets are propagated by a tunnel
that fragments packets, but this would not raise any backward
compatibility issues:
If a tunnel ingress fragments a packet, it MUST set the outer ECN
field of all the fragments to the same value as it would have set if
it had not fragmented the packet.
As a tunnel egress reassembles sets of outer fragments
[I-D.ietf-intarea-tunnels] into packets, it SHOULD propagate CE
markings on the basis that a congestion indication on a packet
applies to all the octets in the packet. On average, a tunnel egress
SHOULD approximately preserve the number of CE-marked and ECT(1)-
marked octets arriving and leaving (counting the size of inner
headers, but not encapsulating headers that are being stripped).
This process proceeds irrespective of the addresses on the inner
headers.
Even if only enough incoming CE-marked octets have arrived for part
of the departing packet, the next departing packet SHOULD be
immediately CE-marked. This ensures that CE-markings are propagated
immediately, rather than held back waiting for more incoming CE-
marked octets. Once there are no outstanding CE-marked octets, if
only enough incoming ECT(1)-marked octets have arrived for part of
the departing packet, the next departing packet SHOULD be immediately
marked ECT(1).
For instance, an algorithm for marking departing packets could
maintain a pair of counters, the first representing the balance of
arriving CE-marked octets minus departing CE-marked octets and the
second representing a similar balance of ECT(1)-marked octets. The
algorithm:
o adds the size of every CE-marked or ECT(1)-marked packet that
arrives to the appropriate counter;
o if the CE counter is positive, it CE-marks the next packet to
depart and subtracts its size from the CE counter;
o if the CE counter is negative but the ECT(1) counter is positive,
it marks the next packet to depart as ECT(1) and subtracts its
size from the ECT((1) counter;
o (the previous two steps will often leave a negative remainder in
the counters, which is deliberate);
o if neither counter is positive, it marks the next packet to depart
as ECT(0);
o until all the fragments of a packet have arrived, it does not
commit any updates to the counters so that, if reassembly fails
and the partly reassembled packet has to be discarded, none of the
discarded fragments will have updated any of the counters.
During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
the ECN fields of the outer headers being reassembled into a single
packet consist of a mixture of Not-ECT and other ECN codepoints, the
packet MUST be discarded.
A tunnel end-point that claims to support the present specification
MUST NOT use an approach that results in a significantly different
ECN-marking outcome to that defined by the "SHOULD" statements
throughout this section. "SHOULD" is only used to allow similar
perhaps more efficient approaches that result in approximately the
same outcome.
Bob
On 16/05/2019 22:14, Bob Briscoe wrote:
Joe,
Sorry I missed this posting at the time (my mail filters moved both
cross-postings
into my int-area box which I check only rarely).
On 27/04/2019 18:13, Joe Touch wrote:
Cross-posting to let both communities know:
- it would be useful for these documents to address how fragmentation and
reassembly
affects these signals
(esp. if reassembling fragments with different ECN values)
[BB] This is addressed by the re-framing section in ecn-encap-guidelines,
altho it doesn't
give examples of what might have caused frame boundary misalignment, so
fragmentation is
not specifically mentioned. I think I will add an explicit mention of
fragmentation (if
only so a search finds that section).
Actually I've realized that this highlights an inconsistency between the
advice on ECN and
fragment reassembly in RFC3168 and in ecn-encap-guidelines.:
* RFC3168 requires that the ECN marking of a reassembled packet is the
logical OR of the
ECN marks on the fragments,
* whereas ecn-encap-guidelines recommends marking the same number of
outgoing as incoming
octets when reassembling L2 frames or tunnelled packets with different
boundaries -
using a simple counter to track the balance.
In fact, it was the review of RFC3168 by me and Jon Crowcroft back in 2001
that originally
raised the question of how to handle reassembly of ECN-marked fragments..
I'll quote a
passage from the review, which I think justifies the recommendation in
ecn-encap-guidelines
to count marked bytes, rather than use the logical OR of RFC3168:
To use the logical OR of the marking of all fragments might be a pragmatic
solution, particularly for congestion control protocols like TCP where one
loss per round trip is treated identically to many. However, it is
becoming
more common to see large numbers of packets per round trip time as data
rates increase while packet sizes and the speed of light haven't increased
for many years. Therefore it is to be expected that newer congestion
control protocols might take more accurate account of the number of
packets
marked in a round trip. Hence, the inaccuracy of a logical OR during
re-assembly at the IP layer is best avoided.
I'm not too worried about the inaccuracy of using a logical OR, but I
think it best to
recommend more accurate and no less costly counting. The only
justification for the logical
OR was that TCP only reacted to one ECN mark per RTT. But that is changing
now, and the
behaviour of one transport should not be embedded in lower layers anyway.
- it would be useful for these documents to consider
draft-ietf-intarea-tunnels
(which relates to the above) and its discussion on many of the
protocols cited
I can't find anything in draft-ietf-intarea-tunnels that ought to be cited
from
ecn-encap-guidelines or rfc6040-update-shim. Did you have something
specific in mind?
I do want to raise a question about the following sentence, which precedes
the mention of
ECN:
There are exceptions to this rule that are explicitly intended to
relay signals from inside the tunnel to the network outside the
tunnel, typically relevant only when the tunnel network N and the
outer network M use the same network.
Was that last word meant to say "network protocol"?
Then, if that is what you meant, I would disagree. Many different network
protocols include
concepts similar to Diffserv and/or ECN (e.g. IEEE802.1p, MPLS and TRILL
support both,
etc), and there's rarely a reason /not/ to propagate the concept between
different network
protocols when they encapsulate each other, even tho it's not always
straightforward to do
so.
Bob
Bob
Joe
On Apr 26, 2019, at 1:50 PM, Black, David <david.bl...@dell.com>
wrote:
This may be of interest to INT folks who are interested in tunnels and
encapsulations.
Comments by the WGLC deadline are encouraged, but comments after the
deadline
are ok, as they’d have to be dealt with anyway at IETF Last Call.
Thanks, --David
From: tsvwg <tsvwg-boun...@ietf.org> On Behalf Of Black, David
Sent: Wednesday, April 17, 2019 2:51 PM
To: ts...@ietf.org
Subject: [tsvwg] 2nd WGLC on ecn-encap-guidelines and rfc6040-update-shim
drafts, closes 6 May 2019
[EXTERNAL EMAIL]
This email announces a 2nd TSVWG Working Group Last Call (WGLC) on two
drafts:
[1] Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP
draft-ietf-tsvwg-ecn-encap-guidelines-12
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/
This draft is intended to become a Best Current Practice RFC
[2] Propagating Explicit Congestion Notification Across IP Tunnel Headers
Separated by a Shim
draft-ietf-tsvwg-rfc6040update-shim-08
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
This draft is intended to become a Proposed Standard RFC.
This WGLC will run through the end of the day on Monday, May 6, 2019.
Comments should be sent to the ts...@ietf.org list, although purely
editorial comments may be sent directly to the author. Please cc: the
WG chairs at tsvwg-cha...@ietf.org if you would like the chairs to
track such editorial comments as part of the WGLC process.
No IPR disclosures have been submitted directly on either draft
Thanks,
David, Gorry and Wes
(TSVWG Co-Chairs)
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
