Andrew,
Thx for supporting words and offer of help.
At 23:04 04/11/2013, Andrew Mcgregor wrote:
This seems like valuable work. One question is, can we put in scope
notification that losses are NOT due to congestion?
Eyooow. That really does not belong in this scope.
This is about the interface between lower layers and the ECN field in
the IP header. We can't really talk about new semantics in lower
layers that aren't even defined in ECN at the IP layer.
Naively, one could imagine some text treating the ECN field as 4
opaque codepoints, and propagating a similar 4 opaque codepoints
from each lower layer protocol. Then if something new were defined in
IP-ECN like a non-congestive loss codepoint, it could also be defined
in lower layers...
But that's naive, because each lower layer has it's own constraints
and ways of handling concepts like "ECN-capable transport", none of
which easily translates to a simple mapping of codepoints.
Explicit signalling of non-congestive loss is a research problem, because...
* Clearly a link cannot signal that a loss was not due to congestion
using the lost frame itself (there aren't any bits :)
* So the link would have to signal in another frame that didn't get corrupted.
- That frame may go to another process that didn't see any loss;
then what does the process do?
- or the link has to use DPI to signal only in frames going to the
same process as the lost frame.
- that means the link has to understand all transport protocols
There's other hard problems
* A transmission loss doesn't always mean there is no congestion loss
* At my last count, there were at least nine different reasons for
packet loss. If we had 4 bits spare in each lost packet... :)
Bob
Willing to comment and review, at least.
On 5 November 2013 09:03, Bob Briscoe
<<mailto:[email protected]>[email protected]> wrote:
Folks,
Pls respond if you support this being adopted as a work-group item
in the IETF transport services w-g (tsvwg). The WG chairs need
visibility of interest.
Even better, if you're willing to read / comment / review / implement
Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
<<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
Abstract
The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure
interworking between new lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
[Cross-posting tsvwg & aqm, just in case]
Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
<mailto:[email protected]>[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
Andrew McGregor | SRE |
<mailto:[email protected]>[email protected] | +61 4 8143 7128
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
________________________________________________________________
Bob Briscoe, BT
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
