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

From: [email-masked]
Date: Thu, 17 Nov 2005 08:50:34 -0000

If you send more than your reservered amount you have no guarentee on how the network will treat the excess traffic - but many people might just drop the excess - or treat it as the lowest of the low (worse than best effort - higher drop and latency) - so ECN would hardly help then. Certainly packet re-ordering could also occur giving higher jitter, because in a general case you process your reservered and BE traffic in different ways

Further, users value stability more than anything else, expts have shown that users would rather the video run at the lowest (mininum) bandwidth than fluxuate up and then down - ie lower stable network quality gives a higher user experianced quality than average higher quality 

Lou

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Georgios Karagiannis
> Sent: 16 November 2005 16:07
> To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
> Subject: [Tsvwg] Re: [NSIS] interoperability problems between 
> end-to-endECNandedge-to-edge ECN
> 
> 
> 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
> 
> 
> > 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/draf
> t-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
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 17 Nov 2005 03:15:16 -0700

louise.burness,

On Thu, 17 Nov 2005, [email-masked] wrote:

> Further, users value stability more than anything else, expts have
> shown that users would rather the video run at the lowest (mininum)
> bandwidth than fluxuate up and then down - ie lower stable network
> quality gives a higher user experianced quality than average higher
> quality 

I wonder how many in the population this sample group is
disenfranchising. ;)

Best effort over a reserved minimum sounds like a reasonable and
valuable bandwidth allocation policy.  Users whose probability
of survival, or mission success, increases with quality might have
a different perspective on the matter than your home users above.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦