Re: [re-ECN] Two questions about CONEX

[Kevin Mason <[e-mail]>]

> That causes me to wonder where CONEX fits in relative to IPFIX which is
> a mechanism that is designed to monitor the flows in a network and
> report this information to the network operator.
>
> As I noted in a earlier thread, I am also interested in understanding
> why the host needs to use the data packets themselves to indicate the
> expected congestion state to the network rather than using a fate
> sharing OAM mechanism?
>
> - Stewart

I believe it is highly desirable to keep the feedback mechanism as simple as practically possible.

There are broadly two groups involved in an end to end path that should/could have an interest in congestion information. These are

1/ the end user (in reality the user's host on their behalf)
2/ A network provider proving transport resources over part of the end to end path.

IF the feedback was contained in some other protocol like an OAM message then this protocol would have to address the end user's hosts (other wise the end user application will not receive it) and all devices end to end would have to be enabled to forward that additional protocol. Transit devices would need to be able to snoop the separate protocol and relate it to the flow of interest, end hosts would need to support the protocol and also relate it to the flow. To me this is getting more complex than having information inside the underlying protocol that can either be ignored or inspected by transit devices and the flow that the information relates to is unambiguous.

If the feedback is implemented using a layer 4 mechanism (like RTCP)then again this becomes more complex as every layer 4 protocol would need to develop their own implementation and all transit devices would need to recognise all these variants.

Both the above approaches require information to be put in separate packets.

I would imagine that the extraction of this information by a network provider for accounting, be it to trigger end user policy changes and/or to underpin some other commercial construct, is only one use. My assumption is that this feedback information may be used for more immediate mechansims, even to inform some forwarding decisions in intermediate devices. So I would not like to see this potential unnecessarily excluded or made more complex than it needs to be without good reason.

So a key issue seems to be how frequently any interested user host or intermediate party is ever likely to need congestion feedback information and therefore, is putting that information in the lowest layer end to end protocol reasonable to make it available to all likely audiences, or would it be more efficient overall to convey the information less frequently in separate packets using a separate protocol.

IT is conceivable that congestion reporting may be exported by a device using an IPFIX mechanism for some uses. But I do not see that as being suitable for all devices/uses.

IP is the lowest layer that is preserved end to end in most communications today. Some claim end to end Ethernet will become more common, but this has not occurred yet and is not likely to soon, the Internet remains an IP network.

So the key question seems to me to be; 

What is the down side of putting the feedback information in the IP "header"? 

>From a simple transport overhead view, at what point is adding any extension header (assuming that is the IPv6 approach) less efficient than putting the information is a separate packet. 

For some protocol a separate packet might be needed anyway if the frequency of backward responses inherent in the protocol in use is too low for the information to be usefully acted on. I suspect any application using such a protocol will be highly inelastic and would need some higher layer longer duration controls in place to avoid congestion impacts anyway.


Regards
 
 
Kevin Mason

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Woundy, Richard
Sent: Monday, 10 May 2010 8:05 a.m.
To: [e-mail]
Cc: [e-mail]
Subject: Re: [re-ECN] Two questions about CONEX

>For example (and only for example) if they were embedded in the transport protocol itself they would go where ever the transport went.

True. But let's follow this example all the way through. The congestion signal would need to be defined for every transport protocol, right? And how do you account for UDP, since UDP doesn't have any unused/option bits? At a minimum, the congestion signal would need to be defined for RTP/RTCP, SNMP, and proprietary protocols such as uTP.
 
Are you implying that congestion control and monitoring in the network will require deep packet inspection by network elements? Sorry, I do NOT want to be the one carrying *that* message to the network neutrality crowd...
 
-- Rich

________________________________

From: Stewart Bryant [mailto:[e-mail]]
Sent: Sat 5/8/2010 1:32 PM
To: Woundy, Richard
Cc: [e-mail]
Subject: Re: [re-ECN] Two questions about CONEX



On 08/05/2010 14:40, Woundy, Richard wrote:
> So a couple of questions back to you.
>
> 1. I gave the 'CMTS congestion management' as a representative example. But what if I need similar measurements/mechanisms at my backbone interconnects? (That's probably the second place I would need to worry about congestion.) Can these OAM messages make it there?
>   
That would depend on how they are carried. For example (and only for
example) if they were embedded in the transport protocol itself they
would go where ever the transport went.

2. A typical subscriber host is behind one (or more) Ethernet/WiFi home gateways, then behind a broadband modem that may or may not use Ethernet as a layer two transport over the broadband access network. So are we talking about a layer 2 or 3 OAM message? If layer 3, how would a host behind a NAT know who to address it to? (I don't personally like NAT66 but that may be the subscriber's choice rather than mine.) If layer 2, how do I get the subscriber to upgrade all of their home CPE? Plus how many layer 2 technologies need to define this OAM message? Or do we need to define a new home network layer 2 (please no)?

See above.
>
> 3. What if the OAM message needs to be originated by the application/content server side, rather than the subscriber side? How would that server know which CMTS / interconnect router to send it to?
>   
See above.
>
> -- Rich
>
> P.S. The long time constant in the CMTS congestion management feedback loop is dependent on the state of the art today (DOCSIS specs require 15 minute IPDR polling cycle support for the CMTS). In some ways this is a bug, in some ways this is a feature. :)
>   
I agree, but I was not thinking of 15mins, on the other hand I was not
thinking of packet rate which is where I believe current thinking is.

- Stewart


> ________________________________
>
> From: [e-mail] on behalf of Stewart Bryant
> Sent: Sat 5/8/2010 2:24 AM
> To: [e-mail]
> Subject: [re-ECN] Two questions about CONEX
>
>
>
>
> As I was reading the recent email on CONEX I got the impression that a
> lot of the interest in CONEX is to instrument the network so that
> operators can identify the root causes of congestion and understand the
> impact on the network in more detail.
>
>    I also get the impression that at least some of the operators are
> looking for a relatively long time constant in the feedback loop.
>
> That causes me to wonder where CONEX fits in relative to IPFIX which is
> a mechanism that is designed to monitor the flows in a network and
> report this information to the network operator.
>
> As I noted in a earlier thread, I am also interested in understanding
> why the host needs to use the data packets themselves to indicate the
> expected congestion state to the network rather than using a fate
> sharing OAM mechanism?
>
> - Stewart
>
>
>
>
>
> _______________________________________________
> re-ECN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/re-ecn
>
>
>
>
>   


--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html




_______________________________________________
re-ECN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/re-ecn