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

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 9 May 2013 14:00:04 +0000

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.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 9 May 2013 20:23:28 +0200

I agree with what the recommendation says, but don't see the point of having it in the document.
1) it doesn't even mention AQM, 2) the behavior of TCP and SCTP is defined in other RFCs, what's the point of saying "they should actually do this and that"? To guide people diverging from the standards, or prepare future standards? For the first, I'm not sure if we should care much in an RFC about people that don't care about RFCs; for the second, I think we have lots of guidance notes in this direction already (some would be in RFC5783, e.g. RFC2914)

Cheers,
Michael

On May 9, 2013, at 4:00 PM, Fred Baker (fred) <[email-masked]> wrote:

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Vijay Subramanian <[email-masked]>
Date: Thu, 9 May 2013 11:31:18 -0700

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) <[email-masked]> 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.
>
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 10 May 2013 12:52:57 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay Subramanian
Sent: Donnerstag, 09. Mai 2013 20:31
To: Fred Baker (fred)
Cc: [email-masked]
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) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aqm