Subject: Re: [PCN] some comments on pcn-architecture-02

From: Magnus Westerlund <[email-masked]>
Date: Sat, 01 Dec 2007 20:13:37 +0100

Hancock, Robert skrev:
> 
> 6. On the specific point about what to do with PCN flows using ECN, I
> can just about follow the logic
> - if CE was set, then it is possible that it was set by a router using
> the default ECN semantics
> - a router using the default ECN semantics should be able to assume that
> the receiver would react in a similar way as to a packet drop
> - therefore the PCN domain can drop the packet
> However, it's quite a long journey from the beginning of the argument to
> the end. In particular, for an endpoint, receiving a packet with CE is
> quite different from not receiving a packet at all. For one thing, it
> means the receiver gets data. It also gets a positive signal of
> congestion (rather than, for example, wondering whether it was a
> congestive or corruptive packet loss). In general, I think it's really
> important not to do things which act as deployment disincentives for
> ECN, or any additional barriers to alternative semantics, since e2e
> packet marking is so useful for congestion control in some environments
> (multi-hop wireless in particular). 
> 
> If the desire is to have a simple solution for PCN which uses the ECN
> bits for encoding, there might be an alternative: if you detect that a
> PCN-flow is using ECN (because ECT is set on any of its packets), simply
> reclassify that flow as non-PCN and let it pass transparently through
> the domain as non-PCN (e.g. best efforts) traffic. In performance terms
> the flow is getting no worse service than in a pre-PCN world. If you
> really think that there are no use cases for combined ECN/PCN this
> situation will never arise. If applications are developed in the future
> which can exploit ECN for semi-elastic flows, then it becomes a question
> of writing guidelines for application developers to help them either
> interpret signalling protocols (to find out whether their success in
> admission control is being harmed by their use of ECN) or split their
> flows into elastic and inelastic sub-flows, or indeed work out a PCN
> solution which didn't use the ECN bits internally. All of these would
> obviously be a later stage of the work.
> 

I think we very well can see traffic that it makes sense to put onto a
PCN class in the PCN domain but still use ECN end to end. From my
perspective real-time media is never "inelastic" it is rather
semi-inelastic in the sense that it commonly can't adapt freely, both
because of variable bit-rate depending on the source content and the
limited freedom in the encoding to produce different quality/bit-rate
tradeoffs.

And I have to agree that with ECN you need to have some mechanism to
transparent get across the PCN domain if you are ECN enabled or not.
Then you have the ECN nonce and the CE marking.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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