Subject: [Tsvwg] RE: [NSIS] interoperability problems between end-to-end ECN andedge-to-edge ECN

From: [email-masked]
Date: Wed, 16 Nov 2005 09:58:19 -0000

Georgios

Please can you explain the scenario a bit more. I don't understand it yet [I think you have a dccp application, using end-to-end ecn marks, plus an edge-to-edge reservation. I guess I don't understand why someone might be doing this]

Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: 15 November 2005 20:35
To: Briscoe,RJ,Bob,XVR9 BRISCORJ R; [email-masked]; [email-masked]
Subject: [NSIS] interoperability problems between end-to-end ECN andedge-to-edge ECN

Hi Bob

Yes I agree, the admission control based on (pre-)congestion notification
and the severe congestion (or pre-emption) used in RMD and in your
proposal are very similar. The main difference of your proposal compared
to RMD is that the ECN re-marking is used instead of DSCP re-marking.

During the tsvwg meeting, I have tried to emphasize that ECN is designed
to be an end-to-end concept and not an edge-to-edge concept.
When ECN is used for edge-to-edge purposes this might
limit the current and future applicability of the
(end-to-end) ECN concept.

For example, the current and future applicability of the DCCP protocol
might be restricted since streaming applications
might not be able to use the complete semantics of the end-to-end ECN
concept.
This problem can become more severe if streaming applications will be
using DCCP in combination with a QoS reservation (or a Diffserv based
QoS support). Note that this reservation might not go end-to-end, but
for example  end-to-edge.

Best Regards,
Georgios

On 11/10/2005, "Bob Briscoe" <[email-masked]> wrote:

>TSVWG & NSIS,
>
>It's been pointed out that people on the list don't understand what my
>original posting in this thread was about. I was replying to a point made
>by Georgios at the mike in TSVWG without giving context.
>
>Context
>-------
>It is about a difference in approach between RMD (in NSIS) and
>pre-congestion notification (in TSVWG). Among other differences, this one
>is about re-marking on routers within the Diffserv region if they are
>congested.
>
>In both cases, this re-marked traffic is measured for the aggregate
>arriving at the egress of the Diffserv region and if above a threshold,
>admission of new flows to that aggregate is blocked.
>
>The difference is that routers in the interior of the region re-mark
>differently:
>* RMD re-marks to another Diffserv codepoint and doesn't touch the ECN
>field. * Pre-congestion notification re-marks to the CE codepoint of ECN
>and doesn't touch the DSCP.
>
>One of the reasons RMD didn't touch the ECN codepoint was so as not to
>interfere with end-to-end congestion control of the *same* flow.
>
>The pre-congestion notification approach deliberately chooses to re-mark
>the ECN field, on the grounds that it is congestion that is being
>signalled, albeit 'pre-congestion'.
>
>The draft says we think it very unlikely that anyone will be doing
>end-to-end congestion control as well as reserving capacity for the same
>flow. But, we say if anyone can give a good reason why this might happen,
>we can add mechanism to allow both at once. But we don't want to add
>complexity for what seems only a hypothetical requirement.
>
>So now, if you're interested, you can go back to the original posting and
>perhaps understand the context.
>
>Sorry about that.
>
>Then, I'd be interested to hear from anyone who can argue for congestion
>control within a reserved flow.
>
>
>
>
>Bob
>
>PS. As well as wire protocol differences, there are important semantic
>differences in the meaning of a re-marked packet, but we'll we'll try to
>reach consensus with the RMD authors on that off-line first then come back
>to the list with the conclusion.
>
>
>
>At 18:27 10/11/2005, IJ/ETH wrote:
>>Hi All, this link may work better, Attila
>>
>>http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt
>>
>> > -----Original Message-----
>> > From: Georgios Karagiannis [mailto:[email-masked]]
>> > Sent: Thursday, November 10, 2005 6:46 PM
>> > To: [email-masked]; Attila Báder (IJ/ETH)
>> > Cc: Jozef Babiarz; Kwok-Ho Chan; [email-masked]; Lars Westberg
>> > (KI/EAB); Francois Le Faucheur (flefauch); Anna Charny (acharny);
>> > [email-masked]; [email-masked]
>> > Subject: Re: RMD & pre-congestion notification: How edge-edge and
>> > end-end can interwork
>> >
>> >
>> >
>> > Hi Bob
>> >
>> > Thank you for your e-mail!
>> >
>> > Please note that during an IETF meeting in 2000, Lars
>> > Westberg presented
>> > an Internet draft, see bellow, that used the ECN bits for edge2edge
>> > admission control purposes, but it could not become a WG draft.
>> >
>> > http://www.watersprings.org/pub/id/draft-westberg-loadcntr-03.txt
>> >
>> > Best Regards,
>> > Georgios
>> >
>> >
>> > On 11/10/2005, "Bob Briscoe" <[email-masked]> wrote:
>> >
>> > >Attila, Georgios,
>> > >
>> > >[cross-posting tsvwg & nsis]
>> > >
>> > >Below is the mail I sent to you over a year ago solving your
>> > concerns over
>> > >interworking end-end & edge-edge ECN.
>> > >
>> > >The similar text below has been in
>> > ><draft-briscoe-tsvwg-cl-architecture-01.txt> since the initial draft.
>> > >
>> > >As it says, if anyone can identify a genuine need to do e2e
>> > congestion
>> > >control within a reservation, we have a way to allow it. So
>> > if you have a
>> > >plausible reason for why anyone might ever want this, we are
>> > certainly
>> > >willing and able to accomodate you. But do you?
>> > >
>> > >We don't want to complicate the system if no-one will ever
>> > need it. I can
>> > >construct hypothetical scenarios where cc might be useful
>> > even when you
>> > >have reserved bandwidth, but I can't think of any practical use.
>> > >
>> > >If your concern is purely that we should not second-guess
>> > what people might
>> > >want in the future, you need not worry. Because if cc within
>> > a resv were
>> > >required, a simple extension to the e2e signalling protocol
>> > (RSVP or NSIS)
>> > >would allow the endpoints to say they wanted to use ECN
>> > end-to-end. That
>> > >could be added if the need arose. But I don't see the need
>> > to add it now.
>> > >
>> > >"
>> > >4.3. Egress gateways
>> > >
>> > >    Egress gateways do the following tasks:
>> > >
>> > >---snip---
>> > >
>> > >    o Packet colouring - for CL packets, set the DSCP and
>> > the ECN field
>> > >       to whatever has been agreed as appropriate for the
>> > next domain. By
>> > >       default the ECN field is set to the Not-ECT
>> > codepoint. Note that
>> > >       this results in the loss of the end-to-end meaning of the ECN
>> > >       field. It can usually be assumed that end-to-end congestion
>> > >       control is unnecessary within an end-to-end
>> > reservation. But if a
>> > >       genuine need is identified for end-to-end ECN
>> > semantics within a
>> > >       reservation, then an alternative is to tunnel CL
>> > packets across
>> > >       the CL-region, or to agree an extension to end-to-end
>> > signalling
>> > >       to indicate that the microflow uses an ECN-capable
>> > transport. We
>> > >       do not recommend such apparently unnecessary complexity.
>> > >
>> > >"
>> > >It's really a question of what everyone believes the default
>> > semantics of a
>> > >reservation are today:
>> > >a) end-to-end cc is not being used for reserved traffic?
>> > >b) end-to-end cc is     being used for reserved traffic?
>> > >
>> > >I believe, pragmatically, it is a).
>> > >
>> > >But perhaps you believe the current default position is (b)? If the
>> > >consensus of the TSVWG or NSIS w-gs is with you not me, we
>> > would have to
>> > >define extensions to RSVP and NSIS for the endpoints to flag
>> > that they were
>> > >NOT intending to use end-to-end cc. To reduce complexity, I
>> > would want the
>> > >default for the API to any new signalling stacks to be
>> > REQUIRED to be NO
>> > >end-to-end congestion control required.
>> > >
>> > >Then legacy hosts that want to use end-to-end cc would not
>> > need to signal
>> > >anything new.
>> > >And if application writers using reservations said nothing and their
>> > >application was installed on an operating system compliant with the
>> > >signalling extension it would automatically signal that
>> > end-to-end cc was
>> > >not being used. App writers who wanted to use end-to-end cc within
>> > >reservations would have to explicitly call the API to say so.
>> > >
>> > >Cheers
>> > >
>> > >
>> > >
>> > >Bob
>> > >
>> > >>From: Attila Báder (IJ/ETH)
>> > >>         <[email-masked]>
>> > >>To: "'Bob Briscoe'" <[email-masked]>
>> > >>Cc: "Lars Westberg (KI/EAB)" <[email-masked]>,
>> > >>    [email-masked], "[email-masked]'"
>> > <[email-masked]>,
>> > >>    [email-masked]
>> > >>Subject: RE: RE: Meeting to discuss QoS
>> > >>Date: Tue, 17 Aug 2004 08:33:01 +0200
>> > >>X-Mailer: Internet Mail Service (5.5.2657.72)
>> > >>X-OriginalArrivalTime: 17 Aug 2004 06:33:08.0559 (UTC)
>> > >>FILETIME=[0F6B35F0:01C48424]
>> > >>X-MIME-Autoconverted: from quoted-printable to 8bit by
>> > >>bagheera.jungle.bt.co.uk id i7H6XA7S029034
>> > >>
>> > >>Hi Bob,
>> > >>
>> > >>Thank you for your answers, I will think of them.
>> > >
>> > >[BB 10/11/05]: Haven't seen any response since --- until
>> > Georgios repeated
>> > >the concern in the TSVWG mtg on Tuesday.
>> > >
>> > >>The work mentioned was not published, so I cannot send a
>> > ref. now. The
>> > >>contact person knows our investigation, even if not all the details,
>> > >>please let me know if you do not get answer from him.
>> > >>
>> > >>Best regards, Attila
>> > >>
>> > >> > -----Original Message-----
>> > >> > From: Bob Briscoe [mailto:[email-masked]]
>> > >> > Sent: Thursday, August 12, 2004 1:54 PM
>> > >> > To: Attila Báder (IJ/ETH)
>> > >> > Cc: Lars Westberg (KI/EAB); [email-masked];
>> > >> > [email-masked]'; [email-masked]
>> > >> > Subject: RE: RE: Meeting to discuss QoS
>> > >> >
>> > >> >
>> > >> > Attila,
>> > >> >
>> > >> > Sorry for delay - been meeting a submission deadline.
>> > See below...
>> > >> >
>> > >> > At 15:58 06/08/04, IJ/ETH wrote:
>> > >> > >Hi Bob,
>> > >> > >
>> > >> > >I apologize for the late answer, I was very busy during the
>> > >> > summer and we
>> > >> > >had to discuss your proposal. Yesterday we came together
>> > >> > with Philip and
>> > >> > >Lars for a discussion.
>> > >> > >
>> > >> > >We have the following main comments regarding the
>> > solutions sent us:
>> > >> > >
>> > >> > >We have also investigated similar solutions.
>> > >> >
>> > >> > [BB] Refs?
>> > >> >
>> > >> > >[AB] The main problem we see with ECN marking is that it has
>> > >> > end-to-end scope.
>> > >> > >The default behavior of ECN assumes that the end host switch
>> > >> > on/off the
>> > >> > >marking.
>> > >> >
>> > >> > [BB] We aren't using the default behaviour. I thought
>> > the paper makes this
>> > >> > clear. It says we're using all three of the RSVP, DSCP and
>> > >> > ECN /protocols/,
>> > >> > but none of their /architectures/, that is, we're not using
>> > >> > the Intserv,
>> > >> > Diffserv, or ECN-TCP architectures. We're just using ECN at
>> > >> > the IP layer.
>> > >> > The return path is an opaque object carried by the RSVP RESV
>> > >> > from edge to
>> > >> > edge.
>> > >> >
>> > >> > Traffic that has had a reservation signalled has ECT and a
>> > >> > guaranteed DSCP
>> > >> > turned on at the ingress gateway and turned off at the egress.
>> > >> >
>> > >> > Traffic not under a reservation (either not matching
>> > filterspec, or
>> > >> > matching but overflowing the token bucket) is policed to
>> > >> > ensure it isn't
>> > >> > using the guaranteed DSCP. But ECT isn't touched, allowing
>> > >> > the end systems
>> > >> > to control how congestion is handled.
>> > >> >
>> > >> > We have various (unresolved) options if ECT is already on
>> > >> > when reserved
>> > >> > packets arrive. Obviously we leave it on at ingress, but the
>> > >> > question is
>> > >> > how to know not to turn it off at egress. Two possibilities:
>> > >> > - extend the signalling to say what to do at egress (but this
>> > >> > doesn't cope
>> > >> > with some packets in the reservation having ECT on & others off).
>> > >> > - tunnel between the gateways (wastes header space just to
>> > >> > tunnel one bit)
>> > >> >
>> > >
>> > >---Snip loads of further conversation---
>> > >
>> > >
>> > >
>> > >_____________________________________________________________
>> > _______________
>> > >Notice: This contribution is the personal view of the author
>> > and does not
>> > >necessarily reflect the technical nor commercial direction of BT plc.
>> > >_____________________________________________________________
>> > _______________
>> > >Bob Briscoe,                           Networks Research
>> > Centre, BT Research
>> > >B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.
>> > +44 1473 645196
>> > >
>> > >
>> >
>
>____________________________________________________________________________
>Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
>B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196
>
>

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 16 Nov 2005 11:41:34 +0100

Hi Phil

Please see bellow!

>
> Please can you explain the scenario a bit more. I don't understand it yet
> [I think you have a dccp application, using end-to-end ecn marks, plus an 
> edge-to-edge reservation.
>  I guess I don't understand why someone might be doing this]

DCCP can be used as transport protocol for streaming applications. DCCP uses
end-to-end ECN for congestion control support.

A streaming application might need QoS support. Please note that this QoS 
support can be provided either
end-to-end or end-to-edge or edge-to-edge. This depends on the operators 
that are willing to
support such streaming applications.

Now suppose that such a streaming application that uses DCCP and needs QoS 
support
needs to be processed by a domain that will support the
edge-to-edge ECN semantics, that you are proposing.

Maybe  the DCCP folks could help us in this discussion!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 16 Nov 2005 17:07:04 +0100

Hi Phil

Here is a more concrete example.
Consider that the following streaming application has to be supported:
Video-streaming with rate adaptive coding application that can adapt the
bandwidth but for a feasible service quality it requires a minimum
bandwidth.

The minimum bandwidth is reserved because otherwise the
service is useless. If the network has more capacity it can utilize that
and give the enduser a higher quality with better end-user experience.

This streaming application can very well use ECN and RSVP to handle the 
bandwidth
management.

Best Regards,
Georgios

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, November 16, 2005 10:58 AM
Subject: RE: [NSIS] interoperability problems between end-to-end 
ECNandedge-to-edge ECN

> edge-to-edge reservation. I guess I don't understand why someone might be 
> doing this]
>
> Thanks
> phil
>