[Iccrg] RE: On the deployment of Explicit Rate Notificationprotocols

[Dino LOPEZ]

Hi Michael,

Thank you for reading our draft. Please find my answer below.

On 09/26/2011 01:40 PM, SCHARF, Michael wrote:
> Hi Dino,
>
> the core idea of this framework is to allow only sending rates slower
> than the one of the end-to-end congestion control, right?
>
> This IMHO raises a couple of questions:
>
> * Is there a significant benefit? If a router wants to slow down a given
> flow, it can use ECN markings right now (or just packet drops).
> Additional feedback from the network may enable a more fine-grained
> control, which may improve fairness and convergence speed. But I am not
> sure whether this improvement e. g. to ECN is really significant, if no
> speedup compared to end-to-end is allowed.

Some studies show that binary signaling can lead to underutilization of 
resources if several sources receive the congestion signal in a short 
period of time. Thus, ECN can have the same problem, while protocols 
with more complex feedbacks (like RCP, just to give an example), will 
not (moreover, it will depend on the performance of the ERN protocol).

Also, when not all sources sharing the bottleneck are ECN capable, ECN 
capable sources may yield resources in benefit of those non supporting 
the protocol. IP-ERN does not suffer from that problem either. Suppose 
that a bottleneck link is shared by E2E and E2E-ERN flows. Then 
cwnd_ern_ will not match the current rate so cwnd_ern_ is bigger than 
cwnd_ (forwarding devices using IP-ERN MUST NOT take into account the 
pure E2E traffic to compute a feedback).

I think there is a real interest of IP-ERN when the bottleneck is known 
(e.g. path with satellite links, or heavily load network access links). 
In that case, we could avoid retransmissions while using all the 
available bandwidth. The benefit will increase as the bandwidth x delay 
increases. Some studies shows also that delay-based congestion control 
mechanisms may have convergence problems (e.g. TCP Vegas). Using a ERN 
protocol by mean of IP-ERN may speedup the convergence. Delay-based LBE 
convergence capabilities can also benefit from IP-ERN.

>
> * I think that the equation "cwnd_ = min (cwnd_, cwnd_ern_)" can be
> understood and implemented in two different ways:
>
>    (1): Use one cwnd only. Then, the minumum is taken probably always
> whenever cwnd is updated. But then some corner cases could be tricky, e.
> g., when cwnd is inflated during fast rtx.
>
>    (2): Use a shadow cwnd, i. e., "cwnd_ = min (cwnd_shadow_,
> cwnd_ern_)", wherein cwnd_shadow is updated by the end-to-end algorithm
> independent of ERN. Then one key question is how to deal with
> connections that are limited by cwnd_ern. One might need a kind of
> congestion window validation to ensure TCP compatibility.

We agree with you and we have to clarify this. For (1), we have to 
signal that this equation is not valid during the execution of window 
inflation. This can be achieved by mean of a flag turned on during the 
execution of FRet / FRec (special considerations may be also needed 
regarding to F-RTO).

For (2 hoping I understood your remark). IP-ERN requires cwnd_ be equal 
to cwnd_shadow_. Thus, cwnd_shadow_ must be updated immediately once 
equation 1 is executed.

For (1 & 2). We have to make un update and remark that after the 
execution of eq.1, cwnd_ern_ must be updated (cwnd_ern_ = cwnd_) so the 
feedback from forwarding devices are computed using the right state of 
the sources.

>
> * Apparently, the reseach community failed so far to agree on the header
> information that explicit rate notification would actually need. The
> draft seems to leave that question open. For a framework document, this
> may be OK. But I could imagine that proposals would - at least in theory
> - require also signaling of information in the SYNs. This is not
> foreseen in your architecture, right?
Speaking not as researcher, but as TCPM co-chair: Since you are
proposing at least one new TCP option, please note that TCP option space
in particular in SYNs is somehow scarce.

Absolutely. In this document we didn't want to deal with the header 
construction/position of ERN protocols. Indeed, IP-ERN can be used to 
deploy an ERN protocol like a service and the programmer is free to 
create/place the header as he wants.

Additionally, in this draft we advised (we have to clarify also that 
this is only an advise) to use the TCP option fields to initiate an 
E2E-ERN connection. However, if the cases when IP-ERN can be used is 
strictly defined by a network administrator (e.g. long-lived flows with 
well known receivers), the use of TCP options at SYN packets is not needed.

>
> BTW, I guess that you are aware of the challenges listed in section 3.1
> of RFC 6077.

Yes, I do. We will update the document with references to that RFC.

Best Regards,

Dino

>
> Michael
>
>
>> -----Original Message-----
>> From: iccrg-bounces at cs.ucl.ac.uk
>> [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of Murari Sridharan
>> Sent: Monday, September 26, 2011 10:12 AM
>> To: Dino LOPEZ; michawe at ifi.uio.no; iccrg at cs.ucl.ac.uk
>> Subject: [Iccrg] RE: On the deployment of Explicit Rate
>> Notificationprotocols
>>
>> +iccrg
>>
>> -----Original Message-----
>> From: Dino LOPEZ [mailto:dino.lopez at unice.fr]
>> Sent: Monday, September 26, 2011 1:07 AM
>> To: michawe at ifi.uio.no; Murari Sridharan
>> Subject: On the deployment of Explicit Rate Notification protocols
>>
>> Dear ICCRG chairs,
>>
>> We have submitted a new Internet draft which provides an
>> architecture to allow the deployment of congestion control
>> protocols with explicit rate notification from forwarding
>> devices (Explicit Rate Notification protocols).
>>
>> This draft is currently available at
>> http://www.ietf.org/internet-drafts/draft-lopez-ietf-tsvwg-ipe
>> rn-00.txt
>>
>> We will be grateful if you can relay this information to the
>> ICCRG community and we can receive any feedback from the you
>> all (at http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG
>> it is remarked that one should send an email to the chairs
>> requesting that the ICCRG perform a review of the document)
>>
>> Best Regards,
>>
>> The authors
>> Lochin, Emmanuel (emmanuel.lochin at isae.fr) Lopez Pacheco,
>> Dino (dino.lopez at unice.fr) Sathiaseelan, Arjuna
>> (arjuna.sathiaseelan at gmail.com)
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> Iccrg at cs.ucl.ac.uk
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>