Hi Gorry,
I think my main issues can be resolves with some smaller changes or
additions/removals. However, I still think that this document should not give
any recommendation what a network node or the transport must or should do. The
group has to decided on this, but I guess this would be a large change in the
sections 3-5.
See below.
The main issue is that the text sounds like if you have accECN, you can
just go
ahead
and implement a different congestion control. However, if you use
something like
DCTCP on the Internet, you'd be very aggressive and push away other
traffic.
Therefore we should be more careful what we say here. I'm not even sure if
this
should be discussed in the 'Benefits' section, but I do think it's
important to
mention in this doc. Maybe we can also ask Bob Briscoe what he think
should be in
this section because he has been very actively working on this recently.
GF: I think points are relevant to the TCPM requirements for
Accurate ECN. To me, they seem to be mainly of concern to transport protocol
designers, rather than end-to-end users of the service - Im sure work in
TCPM will consider this, but indeed we could state something here.
Not sure what you mean by ‚end-to-end users of the service‘. For me the
transport protocol or the congestion control of the transport is the user of
the ECN signal. And here we should be careful what we say.
Fo you think this text could cover the point as regard usage of ECN by
upper layer protocols?:
OLD:
This could be used by the control mechanisms in the transport to make a
more appropriate decision on how to react to congestion, allowing it to
react faster to changes in congestion state.
NEW:
This could be used by the control mechanisms in the transport to make a
more appropriate decision on how to react to congestion, allowing it to
react faster to changes in congestion state. Any update to the transport
protocol requires careful consideration of the robustness of the behaviour
when working with endpoints or network devices that were not designed for
the new congestion reaction.
That helps a little buts still doesn’t make me completely happy. The main
problem is co-existence with current traffic. And this probably requires both
the congestion control as well as the AQM to be updated together and makes the
problem more complex. While the current text more reads like, please go ahead
and design a new congestion control OR AQM but be careful… don’t think that’s
enough.
Further it is not only this one sentence; there are more sentences in these
paragraph which say very similar things.
What about basically simply removing these sentences:
OLD:
2.6. Opportunities for new Transport Mechanisms
Loss is regarded as the standard signal from a network device
experiencing congestion. In contrast, CE-marked packets carry an
indication that network queues are filling, without incurring loss.
This introduces the possibility to provide richer feedback (more
frequent and fine-grained indications) to transports. This could
utilise new thresholds and algorithms for ECN-marking. ECN therefore
provides a mechanism that can benefit evolution of transport
protocols.
2.6.1. Benefits from other forms of ECN-Marking/Reactions
ECN requires a definition of both how network devices CE-mark packets
and how applications/transports react to reception of these CE-marked
packets. ECN-capable receiving endpoints therefore need to provide
feedback indicating that CE-marks were received.[RFC3168]provides a
method that signals once each round trip time that CE-marked packets
have been received. An endpoint may provide more detailed feedback
describing the set of received ECN codepoints using Accurate ECN
Feedback [ID.Acc.ECN]. This can provide more information to a
congestion control mechanism at the sending endpoint.
Loss and CE-marking are both used as an indication for congestion.
However, while the amount of feedback that is provided by loss ought
naturally to be minimized, this is not the case for ECN. With ECN, a
network device could provide richer and more frequent feedback on its
congestion state. This could be used by the control mechanisms in
the transport to make a more appropriate decision on how to react to
congestion, allowing it to react faster to changes in congestion
state.
Precise feedback about the number of packet marks encountered is
supported by the Real Time Protocol (RTP) when used over UDP
[RFC6679] and proposed for SCTP [ST14] and TCP [ID.Acc.ECN].
Benefit has been noted when packets are CE-marked earlier using an
instantaneous queue, and if the receiver provides feedback about the
number of packet marks encountered, an improved sender behavior has
been shown to be possible (e.g, Datacenter TCP (DCTCP) [AL1]).
DCTCP is targeted at confined environments such as a datacenter. It
is
