Re: [re-ECN] Name for BoF?

[Tina TSOU <[e-mail]>]

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?
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)?
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?
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?
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?

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
  [e-mail]
  https://www.ietf.org/mailman/listinfo/re-ecn