Re: [re-ECN] use cases in charter? Was: Re: Two questions about CONEX

["Toby Moncaster" <[e-mail]>]

Hi All,

After four hectic months including a change of career, I have decided to get
involved again in the discussions on this list. In particular I wanted to
follow up on this email regarding use cases in the charter. Please accept my
apologies if I am stating the bleeding obvious or repeating something people
have already said, it is going to take me a bit of time to get back up to
speed with all this! I also fear I may be rambling a bit...!

I think we do need to tread a very careful line with the proposed charter.
There are 3 things that it has to achieve:

1) It must be limited enough to give real results quickly (we don't want to
spend years of effort only to end up with a protocol that is superseded
before it is even finalised).

2) It must be open enough to allow a variety of eventual uses for the
resulting protocol. In particular, whilst the charter may well put
significant areas "off limits" it must be careful not to close them off from
future work (ie "x is out of scope for this document" is OK, but "x must
never be done" is not OK).

3) It must be "inclusive". We know (all too well) that there are many
opinions for and against the proposed work. Even those in favour of it
disagree about quite fundamental things. The charter has to acknowledge
this, and has to make it clear that this won't act as a complete block to
progress (luckily the IETF doesn't operate a veto system else we would
really be stymied!). 


Bearing those 3 things in mind we can look at the case for putting use cases
in the charter. My own opinion is that we should be careful about use cases.
Yes, we need to identify that there are several useful use cases in order to
justify putting so much effort into this protocol. However we must avoid the
temptation to get locked into a detailed technical discussion about the
final solution. The IETF guidelines are that the working group should decide
that. At chartering stage it should be sufficient to identify that there are
genuine interesting problems and that there is a genuine potential solution
(both of which have been done repeatedly). 

Having said that, I think there is potentially some benefit in publishing a
(probably very messy) ID gathering together ALL the possible use cases
people have discussed on- and off-list. This wouldn't be part of any formal
process, and it wouldn't matter if some of the cases were contradictory. It
would just give a single point of reference for all these discussions...

Some inline {TM}...


Toby

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Mirja Kuehlewind
Sent: 18 May 2010 13:34
To: [e-mail]
Subject: [re-ECN] use cases in charter? Was: Re: Two questions about CONEX

Hi,

On Monday 17 May 2010 19:24:28 Fred Baker wrote:
> I think this is too narrow a scope. I think the document should describe
> use cases for conex.
Having see all the discussion on the mailing list about use cases, I have to

say yes and no to the question if there should be uses cases mentioned in
the 
charter. 
I think the use case of providing an incentive for endsystem to do
appropriate 
congestion control is an important one. There is already mentioned something

in the charter 

'Today, the network signals congestion by ECN marking or dropping packets,
the 
receiver passes this information back to the sender in transport layer 
acknowledgements, where the sender makes an adjustment to its window size or

data rate as appropriate.'

but with conex there is actually a strong reason for the sender to really 
adjust something. Whereelse with ECN-only the sender might be better off to 
not reducing its sending rate and wait for a stronger sight of congestion 
like a drop when at the same time someone else reduces its sending rate 
already with the ECN marking.

{TM} Well, there is an incentive if there is congestion policing. What conex
actually does is add a mechanism to do something that can't be done at the
moment, namely let the network know how well behaved you are. Currently many
(most?) ISPs assume their customers are being selfish and misbehaving, conex
allows the honest majority to show that they are in fact honest...




Such an incentive can be introduced by an policier at network ingress or 
something else... the actually realization in the network might be out of 
scope for the charter but the mechanism of motivating the sender to actually

do appropriate congestion control (which is not given with ECN-only) should 
be mentioned more explicit IMHO.

I would hope having this use case in mind makes one benefit of conex more 
clear even though there are more use cases especially when regarding the 
network components using this information. But at least for me the 
appropriate congestion control in the endsystem is the focus (in  the first 
step).

{TM} We have to be a little cautious there. Yes, end-system CC is important,
but it is kind of out of immediate scope for conex. The IETF already has
lots of guidance on what end-systems must do in response to congestion.
Frankly, if it doesn't suit them to follow the guidance, application writers
just ignore it! What conex does is delve deeper than that. It adds the
concept of accountability to things. Then the motivation to behave yourself
is created by the risk of being caught misbehaving. Accountability is a
cornerstone of finance, and (with a few sad exceptions) it keeps things
working as they should do.




> Consider RFC 3168 as a prototype for this document. It identifies that the
> network can easily and cheaply flag congestion events (far more cheaply
> than with IPFIX, and far more accurately), but it also identifies that the
> responsibility for responding to the event lies in the transport layer. If

{TM} But PLEASE can we make sure our documents are more clearly written. One
of the weaknesses of RFC3168 is that, because it is relevant to both TCP and
IP it is very hard to cleanly separate out all the different requirements
contained within it...



> you had put this requirement on the authors of RFC 3168, they would not
> have been able to describe what is in fact a very useful capability.
(IMHO,
> either RFC 3168 or a delay-based congestion avoidance procedure in the
> transport would be very sufficient for ledbat, for example).
>
> I don't think you actually need a WG for this document. What you need is
> for individuals that have use cases to post drafts describing them. If
> conex wants to pull those together into a use case document, they can do
> that at their leisure.
I don't see anything in the charter that prohibits to put together such a 
document that collect all the uses cases within the w-g (e.g. starting with 
the ones mentioned on the mailing list already). All those ideas might/will 
influence the protocol design. But it might not be possible to fullfill all 
requirements of all use cases so its good to have one major uses case in
mind 
which should be described in the charter.

{TM} I would actually argue that such a document allows us to then
rationally compare different conex proposals to show how good they are at
being broadly applicable to a range of problems. I do still think we mustn't
limit the charter to a single use-case. Perhaps the solution is to have an
initial use case (or preferably a few initial use cases) in the charter but
make it absolutely clear that these are a just starting point (sort of like
the original PCN charter limitation to only examine cases where trust is
assumed).



Btw. shouldn't the current charter be on the following page...?
http://trac.tools.ietf.org/area/tsv/trac/wiki/re-ECN

And I guess the URL should be change to 'conex' instead of 're-ECN' at a 
time...?

Mirja



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------
_______________________________________________
re-ECN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/re-ecn