Subject: [Tsvwg] RE: RMD & pre-congestion notification: How edge-edge and end-end can interwork

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Thu, 10 Nov 2005 19:27:54 +0100

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 Nov 2005 22:51:17 +0000

TSVWG & NSIS,

It's been pointed out that people on these lists don't understand what my 
original posting in this thread was about (and it bounced anyway because I 
was cc'ing too many people).

The thread started with me replying to a point made by Georgios at the mike 
in TSVWG. Here's the missing context.

Context
-------
The thread 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 try to reach 
consensus with the RMD authors on that off-line first then come back to the 
list with the conclusion.

> > >---Snip loads of further conversation---

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   +44 1473 645196

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Thu, 10 Nov 2005 19:18:47 +0100

Hi All, this link may workw better, Attila

---

From: [email-masked]
Date: Mon, 14 Nov 2005 13:14:12 +0200

Bob,

Just jumping in the middle of the discussion:

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

The NSIS work, as you know, is supporting end-to-end signaling
(as well as end-to-middle signaling, etc.).  From my discussions
with the RMD authors, the feeling is that in some networks
(especially mobile / cellular networks) there might need to
be additional protection for severe conditions that could cause
failure in certain parts of the network due to link failure, etc.
My guess is this wouldn't be in the middle of the network, but
certain links in access networks.  

I'm sure that Attila or Georgios could sketch out a better scenario
for this, but I think for certain deployments, this makes sense.

John

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Mon, 14 Nov 2005 18:24:11 +0100

Hi Bob,

I would not say that ECN marking for rt-traffic will not work (et least edge-to-edge). I am wondering what people think of it. In RMD we use DSCP re-marking that do not have conflict with previous definitions. 

Best regards, Attila

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 10, 2005 10:44 PM
> To: [email-masked]; [email-masked]
> Cc: Georgios Karagiannis; Lars Westberg (KI/EAB); Attila 
> Báder (IJ/ETH);
> [email-masked]; Anna Charny (acharny); Jozef Babiarz; Kwok-Ho
> Chan
> Subject: [NSIS] RE: RMD & pre-congestion notification: How 
> edge-edge and
> end-end can interwork
> 
> 
> 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 
> 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.
> 
> 
> 
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>