Subject: [Tsvwg] [Digest] ECN & fragmentation

From: Bob Briscoe <[email-masked]>
Date: Thu, 08 Mar 2001 10:55:46 +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 (this one)
4. IP's ECN service to other congestion control protocols
5. Summary

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

BB>>At 10:32 21/02/01 -0800, Sally Floyd wrote:
SF>>>Bob -
SF>>>
SF>>>I just reread the section on ECN and fragmentation, and I don't
SF>>>have any strong objections, but I also don't actually see the need
SF>>>to legislate that markable packets MUST have the DF flag set.
SF>>>If some application wants to allow fragmentation, and to deal
SF>>>with the complications of reassembly, I don't see that it does
SF>>>any one else any harm...

BB>>AFAIK, applications don't do re-assembly. That's the problem. 
BB>>If we don't mandate the DF flag, the receiving IP *has to* 
BB>>decide on some re-assembly strategy before it hands it to the 
BB>>app as a fait accomplis. Either that or we add some way for 
BB>>the app to control the strategy (please, no!).

SF>OK, we disagree about this one.

BB:So, if IP stack receives fragments, each marked differently, 
BB:what does it do on re-assembly? Crash? Use frag id 0's mark? 
BB:Logical OR? Tell TCP that Bob & Sally disagree?
BB:
BB:More importantly, if this is left to implementors to decide, 
BB:there will be varying congestion responses. If I were 
BB:Microsoft, I'd decide to use frag 0's mark under 
BB:InternetExplorer and a logical OR under Netscape.
BB:
BB:OK, I could relax my wording to say DF SHOULD be set for 
BB:markable traffic, and it should only not be set if all 
BB:receivers have agreed they can handle it (undefined how). 
BB:Still got the 'Microsoft problem' with this one though. With 
BB:our proposal, the network can protect itself against such 
BB:tricks.

BB>>>>David,
BB>>>>
BB>>>>At 20:56 21/02/01 -0500, [email-masked] wrote:
DB>>>>>-- Section 11
DB>>>>>
DB>>>>>I have no problem with requiring that all ECN-capable
DB>>>>>packets have the DF (Don't Fragment) bit set, but I don't
DB>>>>>see why it's necessary.  The discussion of how to set
DB>>>>>CE on reassembly does not seem to be germane to TCP
DB>>>>>usage of ECN, as the requirement that the sender
DB>>>>>respond to congestion indications at most once per
DB>>>>>RTT should yield the right behavior independent of
DB>>>>>what's done here.

BB>>>>But re-assembly is usually implemented without having looked at the 
BB>>>>protocol field. So whatever is done for TCP will just leak into the 
BB>>>>rest of the protocols by default unless it's dealt with now.

DB>>>Ok, let's say "sender SHOULD set DF in ECN-capable packets"
DB>>>and be done with it.  Any future work on other protocols
DB>>>gets to specify end system behavior for those protocols and
DB>>>can say MUST instead of SHOULD for those protocols.

BB>>If we say SHOULD, we have to cater for the ones that don't. 
BB>>That means saying any transport protocol that chooses not to 
BB>>set DF MUST define the re-assembly behaviour. That means your 
BB>>TCP draft MUST define this. Hence the decision our end to 
BB>>make it a MUST (because it's best practice anyway).

BB>>David,
BB>>
BB>>Following up my own posting, I wasn't thinking straight on
BB>>fragmentation in the mail (what I said in the I-D is OK)...
BB>>
BB>>I'm talking rubbish, ...
BB>>
BB>>...Unless there are major changes to stack architectures (and 
BB>>I see no moves in this direction), a higher level protocol 
BB>>can't re-define IP's re-assembly behaviour. What IP does on 
BB>>re-assembly will be for *all* protocols. So if we put in a 
BB>>SHOULD, and your Proposed Standard or any RFC defines IP's 
BB>>re-assembly behaviour for when DF is not set, then every 
BB>>transport protocol will have to put up with it.
BB>>
BB>>I don't like saying MUST. But there's a fundamental new factor 
BB>>for IP here. Never before has it been possible to receive 
BB>>fragments with different headers (other than the fragmentation 
BB>>related fields, of course). So re-assembly has been 
BB>>straightforward. AFAIK, it's always been the case that, if one 
BB>>fragment is dropped, all remaining fragments received are 
BB>>discarded, because IP has no way to request retransmissions, 
BB>>and it can't give fragments to the transport (the transport 
BB>>header might even be missing).

DB>I agree with Sally - IMHO, the right way to look
DB>at this is to consider each layer 4 protocol to
DB>be a independent user of IP and hence entitled to
DB>instruct IP on how to set DF.  Saying "SHOULD
DB>set DF" is consistent with it being a Best Current
DB>Practice and avoids problems if someone comes
DB>up with something truly clever to do with IP
DB>fragmentation in the future (not that likely,
DB>but one never knows).  Specifically:

BB>>It would be particularly bad for the future if your TCP/IP/ECN 
BB>>Proposed Standard defined logical OR as the re-assembly 
BB>>behaviour for IP (for the reasons given in the third para of 
BB>>our fragmentation section).

DB>I think we have no choice but to do this for TCP
DB>with ECN as TCP is currently defined.  Other protocols
DB>or experiments with changes to TCP may do different
DB>things, and always have the option of saying "MUST
DB>set DF" for their situation rather than SHOULD to
DB>avoid the tarpit that concerns you.

BB>>A little more background to that discussion in that third 
BB>>para:
BB>>As data rates rise, packet sizes and the speed of light seem 
BB>>to remain roughly the same. Hence more packets per RTT. It's 
BB>>quite feasible we will sometimes have thousands of packets per 
BB>>RTT in the future (100Mbps of 1500B packets with 500ms RTT ~> 
BB>>4000pkt/RTT). In such a future, it is unlikely the same 
BB>>reaction (e.g. a window halving) will be expected whether 1, 
BB>>2000, or 4000 marks are received in a RTT. Even though the 
BB>>IETF doesn't have to worry about such transport protocols this 
BB>>month, we have to ensure IP is correct for that day. IPv6 is 
BB>>already correct. Putting a logical OR to combine ECN marks on 
BB>>fragment re-assembly for IPv4 could seriously underestimate 
BB>>the level of congestion being seen in a stream of fragments. 
BB>>This could seriously damage the health of the Internet in the 
BB>>future.
BB>>
BB>>Bob

SF> My advise would be that if someone is standardizing a transport
SF> protocol that uses ECN marks in a way that does not interoperate
SF> well with fragmentation, then they would be advised to specify that
SF> *for their transport protocol*, the senders MUST set DF.  I am not
SF> inclined to mandate it for the entire world, just to save them from
SF> having to remember to mandate for their own transport protocol...
SF> 
SF> - Sally

BB:I presume you aren't currently planning to mandate DF for 
BB:TCP...
BB:
BB:If so, you have to define the re-assembly behaviour of markable 
BB:IP for whenever DF isn't set. Or you could leave it to be 
BB:implementation dependent (reasons against that already given). 
BB:You have to do one or the other. Which one?
BB:
BB:If you say it's logical OR because that suits *today's* TCP, 
BB:this means any other protocol in the future that needs 
BB:re-assembly to be different *can't* have it different (without 
BB:adding a re-assembly control protocol to IP). This includes TCP 
BB:in the future, if it needs amending to be less severe for one 
BB:mark. 
BB:
BB:Or TCP in the future just mandates DF must be set, of course.
BB:
BB:I'm harping on about this, because I don't think people are 
BB:quite seeing that a decision made now cannot be revoked. You 
BB:can't allow choice in the future. You have to decide now.
BB:
BB:Summary:
BB:If you don't mandate DF for TCP, you have to define IP ECN 
BB:re-assembly behaviour in your I-D or allow it to be 
BB:implementation dependent.

________________________________________________________
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