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

[Mirja Kuehlewind <[e-mail]>]

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.

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

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

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