[re-ECN] role of ECN? (was Re: Name for BoF?)

Tina,

> Dear all,
> I definitely have interested in this work. WRT the name of the BoF,  
> I have got used to re-ECN.
>
> Some understanding for the time being is following. Please correct  
> me if I’m wrong.
> 1, ECN is solving network congestion problem by requesting the  
> sender to lower the sending rate. In this way, if congestion occurs  
> for inelastic flow (i.e. the traffic sensitive to delay and jitter,  
> for example voice, video), how does ECN support this service?

I think its important to keep in mind that ECN itself only conveys the  
condition of near congestion somewhere along the path.  That  
information, sent back to the source, then triggers a reaction.  The  
form of that reaction is (from my perspective) open for discussion,  
but by default is assumed to be a reduction of the sending rate.  For  
TCP as a transport, the back-off algorithms are automatically  
triggered.  For voice/video that uses RTP/RTCP, one can have a more  
creative set of reactions because the near-congestive state  
information is pushed up to the application.

As a side note, there are a couple of draft RFCs on the topic of ECN  
support for RTP/RTCP and a joint presentation given at the AVT meeting  
in Stockholm -- minutes are available.  The authors of the drafts will  
pool their efforts into a single approach with a new draft to be  
issued before the Hiroshima IETF.

> 2, when the congestion occurs in the network devices in the  
> aggregation network, the traffic causing this congestion come from  
> many sources. Therefore even some sources have few traffic, they may  
> also receive the congestion notification. As the network is  
> convergent, in the multiple SP case, even the bandwidth of all SP  
> rented is not full, their video or voice service may occur  
> congestion. Presumably they lease the same volume of bandwidth, it  
> will appear that some SP has little traffic, will also receive  
> congestion notification to lower their traffic. Should they lower  
> the traffic (at this time the rented bandwidth of each SP is not  
> full)?

a good question.  My *guess* is that Bob would envision something like  
a future inter-domain variation of Pre-Congestion Notification as  
*one* approach to address this issue, but if not, its something to be  
kept in mind in the debate.

> 3, Regarding the issue of that the source reduces the sending rate,  
> how much should be reduced? As the network interim device is only  
> responsible to mark the congestion, the receiver sends the ECN  
> notification. How to deal with this case?

I don't understand your second question.  As for the first, there may  
not be a single answer.  In the case of TCP, one has the existing back- 
off algorithm as a baseline.  Bob has spoken in the past about not  
always having to be TCP-friendly, so perhaps other less aggressive  
algorithms (eg, that operate over longer periods) may be defined or  
promoted by the group.

> 4, The SP who doesn’t support ECN can benefit from others who  
> support ECN. If some SP does no reduce the rate after receiving ECN,  
> he can benefit form those SPs who react to ECN. (In worse case, it  
> can attack via ECN.)
>
> Regarding re-ECN, there are issues above, but some more question.
> A, In the network, not all devices support ECN, is it the case that  
> in the congestion situation the packets sent by the devices who  
> don’t support ECN will be discarded?

its hard to provide an answer without a more precise definition of  
what you are considering a "device".  If its an end-point (eg, host),  
then it will have had to perform some form of end-to-end negotiation  
in agreeing to support ECN.  If its an intermediate node (router or  
middle box), then *ideally* non-support or non-recognition of the ECN  
field in IP *should* not matter because the packet should be forwarded  
with no additional action taken.  Unfortunately, there are devices and/ 
or SP policies that either zero out the ECN field or drop the packet.   
Hopefully, that will change with related efforts like the Homegate BoF  
and this proposed BoF that exposes this problem.

> B, In congestion case, if the network congests, a new sender sends  
> packets, he will be fined to keep being discarding his sending  
> packets. Should this unfairness be considered?
> C, Each sender/receiver, apply/lease bandwidth before using the  
> network. When the congestion occurs in the network, is it proper to  
> recharge them? In addition, who will be charged? The sender? The  
> receiver?
> D, In addition, the new technique deployment problem, need all the  
> devices to support it. It is a bit difficult to deploy. Another  
> problem is charging. If the access node should do the congestion  
> charging, it makes the network devices heavy. Is it proper for the  
> cost consideration?

the above questions are interesting, but perhaps too specific at this  
time until we have some drafts and more direction as to what the BoF  
will take on in terms of its milestones.

cheers,

-ken

> Some thoughts are following.
> a, The network is open. It is difficult to let the network device to  
> be a police, to control all kinds of service of the user strictly.  
> The more illumination, the more temptation. The improvement of the  
> user experience would be more proper to be placed in the application  
> level.
> b. It should not be very often that the network congestion occurs.  
> If so, that means that the network needs to expanse its capacity.  
> Even the congestion in the flash cloud (peak time) should not be  
> very serious; otherwise the network needs to expands its capacity.
> c, use the existing technique, take good use of flow classification  
> in the egress of each SP, the egress of each special telephone line  
> user; for the up streaming traffic for individual user, except to  
> give the packets for dedicated device (e.g. IP telephony)  
> corresponding priority, put the rest in BE queue.
> d, through some simple technique, to assure the all or most of the  
> users’ experience of inelastic flow (audio, video).
>
> Just my two cents.
>
>
> B. R.
> Tina
> http://tinatsou.weebly.com/contact.html
>
>
>
>
> ----- Original Message -----
> From: Bob Briscoe
> To: re-ECN unIETF list
> Cc: Ingemar Johansson S
> Sent: Tuesday, September 08, 2009 4:03 PM
> Subject: Re: [re-ECN] Name for BoF?
>
> Folks,
>
> More views welcome?
>
> Summary of 'votes' so far...
>
> At 00:08 08/09/2009, João Taveira Araújo wrote:
> >Bob Briscoe wrote:
> >>Folks,
> >>
> >>One important issue I never raised - the name.
> >>
> >>Congestion Exposure
> >>Congestion Visibility
> >>Congestion Transparency
>
> Congestion Exposure seems to get everyone's approval
>
>
> >>And a short form:
> >>CEX?
> >>re-ECN?
>
> Everyone agrees on what it shouldn't be: Not re-ECN
> Less agreement on a replacement:
>
>          CEX
>          ConEx
>          re-con
> Also, one vote for "Wait until later."
>
>
> I'm not so keen on including "Con" for obvious
> reasons :) Choosing something like that can come back and bite you.
> It also sounds somehow as much like config as congestion.
>
> Some time ago, Toby came up with a clever one:
>          C-IT (pron. "See it") for Congestion Information  
> Transparency.
> not so useful if we're not calling it transparency tho.
>
> Hey, I've just had a thought, the flag (or
> codepoint) for rest-of-path congestion could be
> called CEX (Congestion Expected), rather
> ambiguous with ECN's "Congestion Experienced (CE)" tho.
>
>
> Bob
>
>
>
>
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research
>
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn