Re: [re-ECN] CONEX problem statement

> -----Original Message-----
> From: re-ecn-bounces@ietf.org [mailto:re-ecn-bounces@ietf.org] On
Behalf
> Of Mirja Kuehlewind
> Sent: 02 December 2009 19:58
> To: re-ecn@ietf.org
> Subject: Re: [re-ECN] CONEX problem statement
> 
> Hi,
> 
> some little comments below:
> 
> > 1. An applicability statement that consists of
> > A. the functionality /capability that is expected to be provided by
the
> > conex mechanism itself, including its architectural features,
> > limitations and assumptions it makes about networks and end systems
> > B. deployment analysis - how the conex mechanism can be deployed in
> > networks (non vs ECN vs [perhaps] Conex routers) and end systems
> > C. security analysis - threats from falsifying or blanking conex
info
> I'm not sure if you can specify architectural features without having
an
> concret mechanism. Regarding re-ECN this would be droper and policer,
> right?
> There might be different solutions possible...

Was thinking that 1C is analysing the threats, but the actual security
mechanism work (best practices & spec) is done under Item 3[2] (& yes,
this would be re-ecn's dropper or whatever alternative is developed).
the scope of 1A was about the scope of the basic mechanism to 
allow senders to inform the network of the level of congestion they 
expect their packets to encounter.

> 
> 
> > 3. Transport-related Best practices and specifications:
> > [1] for the transport of congestion information from the destination
to
> > the sender,
> > [2] for ensuring the trustworthiness of the conex information
> > Note: capability negotiation is out of scope, except to the extent
that
> > a Conex sender should either be able to work with a legacy
destination
> > or be able to fall-back to non-Conex operation.
> I would say:  [1] requirements for the transport of congestion
> information....

the intention of 3[1] was to describe best practices for the transport,
whether it's implemented in tcp, rtcp or whatever, and secondly to
specify this in tcp. I guess you could call the former requirements
(depending how interpret the term!), but not the latter.

> 
> BR,
> Mirja
> _______________________________________________
> re-ECN mailing list
> re-ECN@ietf.org
> https://www.ietf.org/mailman/listinfo/re-ecn