Subject: [NSIS] Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt

From: Bob Briscoe <[email-masked]>
Date: Fri, 18 Nov 2005 22:14:27 +0000

Georgios, Attila,

To be concrete, I'll ask the question I started with again. Why don't the 
changes to RSVP and NSIS (that I repeat below) resolve the conflict between 
end-to-end and edge-to-edge semantics? The conflict only occurs for flows 
within a signalled reservation, so the conflict can be resolved in the 
signalling. If the conflict is resolved, this proposal should satisfy 
Sally's requirements for specifying alternate semantics for ECN in an 
edge-edge scenario.

[Sally, I'd also be interested in your view - general rules are fine, but 
particular cases like this test the wording.]

I started the earlier thread with this proposal, but as so often happens, 
the very first reply didn't answer the question, then everyone who joined 
the thread continued to "lose the thread". The archived posting is at:
<http://www1.ietf.org/mail-archive/web/tsvwg/current/msg05773.html>

---start repeated text---

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.
---end repeated text---

As I also said in the original posting (and we said in our draft), it's 
only worth making this change to RSVP (and NSIS) if there is any hope of it 
ever being necessary. That discussion is still continuing on the lists.

Bob

At 05:21 18/11/2005, Sally Floyd wrote:
>Georgios -
>
> >In my opinion, the draft-floyd-ecn-alternates-02.txt  could emphasize
> >which are the requirements that the
> >edge-to-edge ECN semantics should fulfill such that the
> >current and future applicability of the (end-to-end) ECN concept
> >is not limited.
>
>I agree.
>
>My proposal would be to add the following section to
>draft-floyd-ecn-alternates-02.txt:
>
>   "Proposals for Alternate-ECN with Edge-to-Edge Semantics"
>
>   RFC 3168 specifies the use of the default ECN semantics by an
>   end-to-end transport protocol, with the requirement that "upon the
>   receipt by an ECN-Capable transport of a single CE packet, the
>   congestion control algorithms followed at the end-systems MUST be
>   essentially the same as the congestion control response to a *single*
>   dropped packet" [RFC3168, Section 5].  In contrast, some of the
>   proposals for alternate-ECN semantics are for ECN used in an
>   edge-to-edge context between gateways at the edge of a network
>   region, e.g., for pre-congestion notification for admissions control
>   [BESFC05].
>
>   When alternate-ECN is defined with edge-to-edge semantics, this
>   definition needs to ensure that the edge-to-edge semanatics do not
>   conflict with a connection using other ECN semantics end-to-end.
>   One way to avoid conflict would be for the edge-to-edge ECN proposal
>   to include some mechanism to ensure that the edge-to-edge ECN is
>   not used for connections that are using other ECN semantics (standard
>   or otherwise) end-to-end.  Alternately, the edge-to-edge semantics
>   could be defined so that they do not conflict with a connection
>   using other ECN semantics end-to-end.
>
>Feedback would be welcome.
>
>- Sally
>http://www.icir.org/floyd/
>
>_______________________________________________
>tsvwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tsvwg

____________________________________________________________________________
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 

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 19 Nov 2005 13:39:57 +0100 (MET)

Hi Bob

The streaming aplication example that has been discussed in
the tsvwg and nsis mailing lists shows that it is usefull to use
end-to-end ECN based congestion control for reserved traffic.
This streaming application example can very efficiently use RSVP and the
DCCP protocol (which uses the end-to-end ECN concept).

One can think of situations (applications) where it is not needed to use
end-to-end cc for reserved traffic. Thus I would say that a third option
should be available in the selection process:
c) the ability of using end-to-end ECN based congestion control for
reserved traffic should be possible. Meaning that for some applications
you may use end-to-end ECN based congestion control for reserved traffic
and for other applications you may not use end-to-end ECN based
congestion control for reserved traffic.

Regarding your following proposal:
>To reduce complexity, I would want the

Are you actually indirectly saying that whenever the IETF standardizes a
new signaling protocol this protocol MUST not be used in combination
with the DCCP protocol (which actually uses the end-to-end ECN concept)?

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 21 Nov 2005 10:52:22 +0100

Hi Bob

In addition to the previous discussion I would like to
discuss and ask you the following.

As you already mentioned the admission control based on congestion 
notification
and severe congestion [pre-emption] described in RMD,
(see http://www.watersprings.org/pub/id/draft-ietf-nsis-rmd-04.txt),
and in your proposal are very similar (almost identical), in terms of
protocol semantics.
The main difference is related to the fact that RMD uses DSCP re-marking
while you are willing to apply ECN re-marking (in an edge-to-edge ECN 
scenario).

>From the previous discussions we have seen that there are interoperability
problems between the end-to-end ECN semantics and edge-to-edge ECN 
semantics.
The DSCP re-marking does not generate such interoperability problems.

Thus my question is:

What is the technical reason of using ECN for edge-toedge congestion 
control,
when the same solution (on providing admission control
based on congestion notification and severe
congestion [pre-emption]) can be provided by using DSCP re-marking?

Best regards,
Georgios

----- Original Message ----- 
From: "Georgios Karagiannis" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, November 19, 2005 1:39 PM
Subject: Re: [Tsvwg] Re: additions on draft-floyd-ecn-alternates-02.txt

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Nov 2005 00:27:46 +0000

Georgios,

Replies inline

At 12:39 19/11/2005, Georgios Karagiannis wrote:

>Hi Bob
>
>[GK] The streaming aplication example that has been discussed in

[BB] See the other mail I've just sent on the Subject: "why use 
edge-to-edge ECN re-marking when DSCP re-markingcan do it".

In summary, yes, this hybrid rate adaptive congestion control with a 
reserved minimum bound rate would probably be useful, but it is not the 
service we are defining.

Our aim is to provide a Controlled Load service that scales well for the 
global Internet. We don't have a way to scale admission control to the 
Internet for traffic that is a hybrid of adaptive and reserved in the same 
flow. I believe you will find that none of the RMD mechanisms based on MBAC 
will be able to make this hybrid service scale well either (see below for 
why).

The only known way to provide this hybrid service is with an Intserv 
per-flow scheduler, which doesn't scale well. Even then the service has to 
be provided with no warranty, because bad packet re-ordering may well 
result (see my quotes from RFC2211 in the other mail).

So I suggest applications need to specifically signal if they want this 
hybrid service. And if operators wish to provide it, they will have to 
classify traffic into a hop by hop Intserv path. This won't scale to the 
Internet, but that is the limit of current knowledge.

A hybrid of adaptive and reserved traffic within the same flows breaks 
measurement-based admission control for the following reason. If congestion 
on an interior path in our scheme or in the congestion-based RMD scheme 
were close to the threshold where admission control was needed, adaptive 
traffic might temporarily drop well below its minimum bound. More flows 
might then be accepted, then the adaptive traffic could grow again, 
destroying the controlled load service for all flows through that path.

[BB] [Nonetheless, we have shown our measurement-based admission control 
scheme can handle variable bit rate (VBR) like video (and 
silence-suppressed voice). We can specify the safety margin needed on the 
virtual queue for a given amount of traffic aggregation, as long as VBR 
sources aren't correlated with each other. But MBAC will never be able to 
manage adaptive traffic, because its load is negatively correlated with 
congestion, which breaks any MBAC mechanism---not just ours but yours in 
RMD as well.]

>[GK] One can think of situations (applications) where it is not needed to use
>[GK] Regarding your following proposal:
> >[BB] To reduce complexity, I would want the
>[GK] Are you actually indirectly saying that whenever the IETF standardizes a

[BB] You have taken the quote out of context. In the thread below, it was 
in the context of new implementations of RSVP or NSIS signalling 
stacks---if the option I proposed became standardised in RSVP or NSIS to 
signal the choice between adaptive or non-adaptive Intserv controlled load 
service (or the equivalent for RMD).

In this context, yes, I mean that TCP congestion control or DCCP congestion 
control would NOT be appropriate for a flow that had signalled that it 
would not use congestion control.

I am saying that it would be a mistake to define an admission controlled 
reservation service for controlled load to cover both cases (adaptive and 
non-adaptive) in the same service. I now believe it was a mistake for 
Intserv to try to do this. We have realised that lumping both services 
together under one service definition means you can't use any form of MBAC 
for non-adaptive traffic, just in case you have adaptive traffic. That 
limits the available mechanisms far too much.

I appreciate that QoS service definitions should be independent of the 
mechanism used to achieve them. But in this case, two related services were 
lumped together because it was thought they could be achieved with the same 
mechanism.

Caveat: No-one has tried to implement this hybrid service with MBAC, so I'm 
talking theory not practice here. But when the authors of 
<draft-briscoe-tsvwg-cl-architecture-01.txt> got together in Vancouver we 
came up with the same hybrid scenario that you have, and none of us could 
see how MBAC could work with it, so we believe it should be excluded 
explicitly.

I would still be interested in your views on the proposed protocol defaults 
as well as the API defaults in the proposal below, now that I have 
clarified the context.

Also, if I am right, what do you intend to do about precluding adaptive 
flows from your MBAC schemes in RMD? It seems this will require changes to 
standards track protocols, along with the other changes to standards that 
RMD will require, if we are to ever see interoperable RMD products.

Cheers

Bob

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