home *** CD-ROM | disk | FTP | other *** search
/ ftp.ee.lbl.gov / 2014.05.ftp.ee.lbl.gov.tar / ftp.ee.lbl.gov / email / sf.97nov19A.txt < prev    next >
Text File  |  1997-11-19  |  3KB  |  65 lines
  1. To: curtis@ans.net
  2. cc: end2end-interest@ISI.EDU
  3. Subject: Re: Internet Draft on Explicit Congestion Notification 
  4. Date: Wed, 19 Nov 1997 16:06:20 PST
  5. From: Sally Floyd <floyd>
  6.  
  7. Curtis -
  8.  
  9. >OK.  I agree that ECN for IPv6 and TCP is a good idea and that we need
  10. >negociation in TCP and 2 bits in IPV6 and/or TCP.  Now what?
  11. >
  12. >How do we format the TCP option and where do we put the 2 bits?  Isn't
  13. >the draft incomplete without this or is this just intended to be
  14. >informational?
  15.  
  16. You are right, the current internet draft is not a complete detailed
  17. proposal.
  18.  
  19. Our assumption is that the detailed proposal for formatting the TCP
  20. option will be relatively straightforward, and can wait until after the
  21. ECN bits are actually allocated somewhere.  As far as I know, the Area
  22. Directors and Working Group co-chairs have not yet finally decided
  23. whether the standardization of the TCP option (and accompanying email
  24. discussion) would happen in tcplw (TCP Large Windows) or in tcp-impl
  25. (TCP Implementers).
  26.  
  27. The question of where the bits would come from in the IP header is more
  28. complicated.  The tentative plan for IPv6 had been that the IPv6 ECN
  29. bits would come from taking two bits away from the 24-bit Flow Label
  30. field.  This discussion (and decision) will have to happen in the ipng
  31. working group.  (I gave a brief presentation about ECN to that working
  32. group at the last IETF.)
  33.  
  34. The task of defining the TCP option, in our perception, is fairly
  35. simple (and is defined in general form in the draft):  define an option
  36. for ECN that is negotiated at TCP connection setup time, and define an
  37. ECN-Notify bit in the TCP header to carry the ECN-Notification back to
  38. the sender.  The work of translating the received ECN bits back to the
  39. ECN Notify bit is straightforward.  (The main decision to be made
  40. is whether to allocate an ECN-Notify bit in the TCP header (as recommended
  41. in our draft) instead of using an ECN option to carry the ECN notification
  42. from the receiver to the sender.  Not too earth-shattering...)
  43.  
  44. The new question is whether it would also be good to allocate ECN bits
  45. in IPv4.  We did not originally consider this, because at the time it
  46. did not occur to us that it would be a possibility.  The detailed
  47. discussion of which IPv4 bits (if any) would be allocated for ECN would
  48. have to happen in intserv, as these bits would "compete" with other
  49. intserv proposals to use freed-up bits in the IP TOS and Precedence
  50. fields.  (I am not up-to-date on all of the discussions on int-serv, and
  51. quite honestly don't know whether there are likely to be one or two
  52. bits in IPv4 for ECN or not.)  We are assuming that the general discussion
  53. of whether ECN is or is not sufficiently compelling would happen on
  54. end2end-interest.  Any feedback on this from the folks involved in the
  55. intserv proposals will obviously play a part in whether we suggest that
  56. IPv4 also consider ECN.
  57.  
  58. (I am writing something today to address the one-bit vs. two-bit
  59. issue.  I personally don't have a preference; the one-bit and the
  60. two-bit implementations would be functionally fairly similar.  There
  61. are some who would argue that the two-bit approach is more robust, and
  62. leaves less room for incorrect implementations.)
  63.  
  64. - Sally and K.K.
  65.