Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5

Hi Fred,

I agree with Vijay and Michael;

The last four words of the title can also be confusing [to the session, other flows, ...] (without incurring loss or undue round trip delay).

If such a section remains, I'd argue against naming of specific protocols; from a router / AQM POV, it might be worthwhile to mention what an AQM SHOULD NOT do considering common congestion control algorithms (ie. delay the congestion signal - obviously; drop  entire flights or lots of consecutive packets of one flow - difficult without state; drop/mark retransmitted packets  - again difficult without a means to identify them. RFC3168 for TCP (SCTP) recommends, however, that retransmissions should not be ECT marked. However I am dubious about the claimed benefit; a lost (as the only means to signal persistent congestion) retransmitted segment is WORSE than a lost original packet (which carries ECT, and would only receive a CE mark). Also, Linux seems to ignore that specific paragraph in RFC3168...).

So, without focusing only on TCP CC - are there any scenarios where an AQM could overshoot and elicit too much of a reaction from a transport CC [dropping a retransmitted segment will cause a RTO with IETF spec'd TCP/SCTP]? If they are general (ie. applicable to SCTP, DDCP, [RTMFP]...), documenting them in this document seems reasonable.

Best regards,

Richard Scheffenegger

From: aqm-bounces@ietf.org [mailto:aqm-bounces@ietf.org] On Behalf Of Vijay Subramanian
Sent: Donnerstag, 09. Mai 2013 20:31
To: Fred Baker (fred)
Cc: aqm@ietf.org
Subject: Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #5

Hi Fred,

A couple of points.
1: The recommendation mentions TCP and SCTP but not transports such as DCCP. I assume the recommendation holds for all transports.
2: The focus of this draft seems to be on AQMs and the other recommendations seem to deal with actions that routers can take. I am not sure what action
 on the part of a router is being recommended here. If this goal can be achieved using ECN, it is already covered in recommendation #2.

Thanks,
Vijay

On 9 May 2013 07:00, Fred Baker (fred) <fred@cisco.com<mailto:fred@cisco.com>> wrote:
Do we generally agree with the recommendation of http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.5? This is the question of TCP/SCTP Congestion Control: I would like to, as a community, recommend that it maximize throughput while minimizing delay, which is to say, do so without being overly aggressive.

_______________________________________________
aqm mailing list
aqm@ietf.org<mailto:aqm@ietf.org>
https://www.ietf.org/mailman/listinfo/aqm