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

From: Bob Briscoe <[email-masked]>
Date: Thu, 10 Nov 2005 15:58:45 +0000

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: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 10 Nov 2005 18:46:11 +0100 (MET)

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