Subject: [Tsvwg] [Digest] IP's ECN service to other congestion control protocols

From: Bob Briscoe <[email-masked]>
Date: Thu, 08 Mar 2001 10:55:54 +0000

tsvwg,

Here's a continuation of the digest of the off-line discussions 
that went on between:
1/ two of the authors of standards track "The Addition of Explicit 
Congestion Notification (ECN) to IP" 
(draft-ietf-tsvwg-ecn-{01|02}.txt Ramakrishnan, Floyd, Black) 
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-01.txt
and 
2/ the new "An Open ECN Service in the IP layer" 
(draft-ietf-tsvwg-ecn-ip-00.txt Briscoe, Crowcroft).
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-ip-00.txt

The 5 digests are:
1. Fourth ECN code-point
2. ECN & diffserv
3. ECN & fragmentation
4. IP's ECN service to other congestion control protocols (this one)
5. Summary

    DB> = David Black
    JC> = Jon Crowcroft
    SF> = Sally Floyd
    BB> = Bob Briscoe

SF>>>At 09:58 21/02/01 -0800, Sally Floyd wrote:
     [Re: Section 8 of draft-ietf-tsvwg-ecn-ip-00.txt] 
SF>>>On another front, I am quite concerned about the use of ECN for
SF>>>non-TCP traffic, and, with several co-authors at ACIRI, am writing
SF>>>a draft (to submit by Friday) proposing a new UDP-ish transport
SF>>>protocol for unreliable unicast flows, that would be essentially
SF>>>UDP with ECN-capable congestion control added.  

BB>>I've nearly completed writing a paper on a multicast cc scheme 
BB>>using ECN myself.

SF>>>But this is a
SF>>>separate issue from the current draft, and will have to work its
SF>>>extremely slow and laborious path through the standards process,
SF>>>with many changes along the way.

BB>>Agreed.

SF>>>I don't think that random IETF documents (such as our ECN draft)
SF>>>can or should have any power to legislate general policy for
SF>>>the Internet.    Thus, my own opinion would be that statements such
SF>>>as "any higher layer protocol MUST be able to assume these 
SF>>>services will be available to it" 

BB>>I thought this was a statement of fact, not a new policy. 
BB>>Another way of saying "don't expect routers to examine the 
BB>>protocol field". 

SF>It don't think it is a statement of fact at all.  I think it is an
SF>open issue how operating systems in end-nodes will control who 
SF>does or does not get to set ECT.  Particularly if there is not some
SF>ECN nonce to protect against misbehaving receivers.

BB:Old chestnut: A service interface provides a capability. 
BB:Access control on the interface may remove it from 
BB:certain parties. The former is the context I'm talking 
BB:in, in this section. Latter is outside scope, as you say. 
BB:Former is important in the context of the IP service 
BB:layer.
BB:
BB:To be clear, I clearly say I'm talking about the top 
BB:interface of the IP layer, not interfaces of higher layer 
BB:protocols (they're in host reqs). On Unix, say, access to 
BB:this is nicely controlled in the kernel.

SF>>>or "All new or updated congestion
SF>>>control protocols standardised through the IETF MUST be defined
SF>>>for markable packets" 

BB>>OK, over-zealous here (I detect Jon agrees). I'll fix it.

SF>>>are doomed from the start, and, if attached
SF>>>to an internet-draft such as ours, are a sure way to guarantee
SF>>>that it never progresses any further along the path to standardization.
SF>>>I have worked for eight years now, on and off, trying to get ECN
SF>>>to standardization, so I would be very sorry to see it derailed
SF>>>so close to the end, but we shall see.

BB>>I'll take this particular plank off the rails.

BB>>>David,
BB>>>
BB>>>At 20:56 21/02/01 -0500, [email-masked] wrote:
DB>>>>-- Section 8
DB>>>>
DB>>>>I'm not sure I see the point of Section 8.
DB>>>>Any higher level protocol that uses ECN has to document
DB>>>>how it uses it.  The first two bullets would seem to
DB>>>>be an obvious part of such a document - since IP has
DB>>>>no congestion control mechanisms, ECN has to be passed
DB>>>>through it to the higher level protocol that understands
DB>>>>what it's doing.  I guess a reference to the congestion
DB>>>>control principles RFC (2914) wouldn't hurt, though.

BB>>>Put it this way. AFAIK, most network software vendors (e.g. Microsoft, 
BB>>>etc) implement anything that's on standards track. If ECN is added for 
BB>>>TCP only, most networks treat all protocols the same. It won't care 
BB>>>whether it's TCP or not. So if someone implements an ECN-capable UDP 
BB>>>datagram sender, someone else can implement a receiver. So I'm just 
BB>>>documenting the internal interface you've defined between TCP and IP 
BB>>>for ECN, which is the same for any protocol. Nothing new. Just making 
BB>>>clear what isn't clear already.

DB>>>>The third bullet seems problematic and confusing -
DB>>>>this is one way of looking at ECN, but not the only
DB>>>>one, and the footnote about how TCP with the ECN
DB>>>>modifications does something different but still
DB>>>>supposedly conforms makes my point.  FWIW, I'm not sure
DB>>>>I believe the footnote, because it's not clear to me
DB>>>>how TCP is responding to the average marking or drop
DB>>>>rate, with the possible exception of time frames
DB>>>>sufficiently long enough to be meaningless.  Once we
DB>>>>get into significant multiples of the RTT, I'm not
DB>>>>sure the notion of average marking rate makes any
DB>>>>sense, and responding at most once per RTT is a
DB>>>>crude approximation of responding to the average
DB>>>>marking rate.

BB>>>Again, I was just trying to state the interface that IP offers. It 
BB>>>exposes the average marking rate from the marking algorithm. My 
BB>>>statement of that is correct. Your point it correct about TCP not 
BB>>>matching this rate very well. That's why I said "tends to". But I'm 
BB>>>defining the IP interface, not the behaviour of TCP here. Aside from 
BB>>>the fact that most people use the version of the RED algorithm that 
BB>>>doesn't weight for packet size, I believe what I've said is a correct 
BB>>>statement.
BB>>>
BB>>>The difficulty here stems from my very last question to Sally. Your 
BB>>>I-D would have been better as two documents (but appraently you 
BB>>>weren't allowed to). When people write UDP ECN protocols in the coming 
BB>>>months, they will have to refer to your Proposed Standard for the IP 
BB>>>bit they sit on top of. But because you've got it all tied in with 
BB>>>TCP, you haven't needed to define the internal interface within your 
BB>>>document between the two. I am trying to do that for you. To help 
BB>>>people in the future.
BB>>>
BB>>>
BB>>>I guess I should have foreseen this might make you all feel 
BB>>>criticised. I didn't intend that. I'm trying to help.

DB>>I can deal with adding words of advice to the next set of
DB>>people who have to write the "using ECN with <foo>" documents,
DB>>even though a lot of it ought to be clear from context.
DB>>I'd stay away from claiming to define a formal interface,
DB>>but convey similar content is a different fashion.

BB>OK.

DB>>>>-- Section 9
DB>>>>
DB>>>>I agree with Sally's comment on the first sentence of
DB>>>>Section 9.  

BB>>>Fixed.

DB>>>>The rest of this section is covered by comments
DB>>>>on Section 5.2 above.
DB>>>>
DB>>>>-- Section 10
DB>>>>
DB>>>>This seems to be headed into the area of specifying APIs
DB>>>>or API-provided services that the IETF usually stays out of,

BB>>>I must admit I was thinking of the lack of ECN parameters in some OSs 
BB>>>when reading a socket, and how to encourage implementors to add them.

DB>>>>and the SHOULD in the first paragraph opens up a security hole
DB>>>>in that exposing ECN at the API for something like UDP
DB>>>>makes it very easy to write an application that uses
DB>>>>ECN but ignores the congestion indications vs. the
DB>>>>current situation of needing to send raw packets.

BB>>>We could also build houses without doors and windows to irritate 
BB>>>thieves. Sorry for sarcasm. But couldn't think of a better way to 
BB>>>respond. I think you get my point.

DB>>-- Section 10
DB>>
DB>>I agree with Sally that encouraging exposure of ECN in
DB>>general is not a good idea at the moment.

BB>OK - can be in our I-D as the start of a longer process.

DB>>>>-- Section 12

BB>>At 11:35 21/02/01 -0800, Sally Floyd wrote:
SF>>>Feedback on Section 12, proposing rules for allowing proxies in the
SF>>>network to change ECN codepoints:
SF>>>
SF>>>I think that this is complicated, and has to be dealt with in a
SF>>>separate document, in context.  That is, when people have specific
SF>>>proposals for intermediate nodes to modify the ECN field, 
SF>>>then I think they have to be addressed at that time.  My own opinion
SF>>>is that making general rules ahead of time, in the abstract,
SF>>>such as "we will now propose rules for changing the ECN
SF>>>capability of a packet at intermediate nodes", never gets it right.

BB>>One could say exactly the same about tunnels. Yes, it's 
BB>>complicated. But migration from 'legacy' tends to be. 

SF>I don't think it is the same.  The issues about ECN and tunnels are
SF>quite straightforward - don't send packets with ECT if the router's
SF>CE indications are going to be simply thrown away.  The issues with
SF>intermediate nodes setting CE seems fine to me, but it involves
 BB>>                         ^^
 BB>>I assume you mean ECT
SF>quite new functionality, and I don't believe that such behavior can be
SF>standardized correctly in the abstract, without specific proposals
SF>as guides.

BB>>OK, we've built one scenario of this cc proxy. Just have 
BB>>to run the experiments and write about it. I just wanted 
BB>>to raise the main issues about the changability of 
BB>>markability at intermediate nodes, and generalise it 
BB>>with the discussion on tunnels.
BB>>
BB>>I deliberately just wrote the I-D as a set of 
BB>>'conclusions' with bare bones motivation. I prefer to see 
BB>>motivation (in a standard) by referring out. I'm sure 
BB>>implementors do too. Problem was, this had to be done in 
BB>>parallel to the write-ups, as it was already late. But 
BB>>from the research we'd done, we could see we needed to 
BB>>protect some space.

SF>I don't think that this draft is the place to address that issue one
SF>way or another.

BB:OK. Agreed. I'll leave it in our draft, but I won't push 
BB:this further. Your I-D doesn't prohibit what we're doing. 
BB:So it's fine. I was just trying to make the semantics 
BB:crystal clear in case implementors could make assumptions 
BB:that drive against what we are doing.

DB>>>>The overall point of this Section seems to be to provide
DB>>>>sufficient room for experimentation with congestion control
DB>>>>proxies.  IMHO, it'd be simpler to add a few sentences
DB>>>>describing how such a proxy would function and making it
DB>>>>clear that the discussion of what a "router" may and may not
DB>>>>do does not apply to such proxies - which would be a topic for
DB>>>>future research and experimentation.

BB>>>The subject was raised as it affects end-to-end authentication 
BB>>>headers. I didn't want to go into any detail beyond needing to state 
BB>>>what might be changed, and in what circumstances. I couldn't tie it 
BB>>>up, because we're still discussing the fourth code-point, so a two 
BB>>>forked discussion on authentication would have got really confusing.

DB>>>>FWIW, the third bullet and footnote 3 on p.10 seem to conflict
DB>>>>with the discussion of setting not setting ECT on retransmitted
DB>>>>packets.  

BB>>>Yes, you're correct.

DB>>End to end authentication should not be touching the
DB>>ECN/Diffserv octet (e.g., IPSec AH doesn't) -- woe betide
DB>>those who do otherwise.  Can we agree on writing a few
DB>>sentences on how a congestion control proxy ought to
DB>>work, and make sure to exempt it (as well as multicast
DB>>packet duplication) from the description of how a "router"
DB>>does ECN?

BB>This will have to be done, but not today - I'm out of time, 
BB>I'm afraid. It's school holidays here, and my family are 
BB>waiting to go out!

________________________________________________________
Notice: This contribution is the personal view of the 
author and does not necessarily reflect the technical nor 
commercial direction of British Telecommunications plc.
________________________________________________________
Bob Briscoe      http://www.labs.bt.com/people/briscorj/

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