Subject: [re-ECN] re-ECN I-Ds

From: Bob Briscoe <[email-masked]>
Date: Tue, 26 Jun 2007 17:51:42 +0100

Folks,

Now we've given people a little time to join this list, let's get started. 
Welcome to the [email-masked] list!

First thing I've got to do is update the I-Ds on re-ECN as they've both 
expired. I have already done a lot of little updates to my local copies, 
but I just wanted to ask ...

Q1. Has anyone noticed anything they would like me to update (other than 
the obvious parts that say "ToDo")?
Q2. Are there any bigger changes wanted (and would you be a willing 
co-author for these), perhaps after Chicago?

Here's my locally archived copies:

1/ "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP"
draft-briscoe-tsvwg-re-ecn-tcp
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#retcp>

2/ "Emulating Border Flow Policing using Re-ECN on Bulk Data"
draft-briscoe-tsvwg-re-ecn-border-cheat
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#repcn>

I'm going to try to update the latter (border-cheat) one before the -00 
deadline next Mon so I can change its name to reflect its relevance to the 
PCN w-g:
draft-briscoe-re-pcn-border-cheat

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
re-ECN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/re-ecn

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Jun 2007 07:50:50 +0200

Hi,

This is probably a stupid question, and surely I'm missing something -
but then again, this will make the question easy to answer:

Why don't use use bit 0 of the "Flags" field in the IPv4 header instead
of the ECN bits? (as for IPv6, that's a different story - but hmmm,
who needs 20 bit for a flow label?  :-)   )

Cheers,
Michael

---

From: Dennis Rockwell <[email-masked]>
Date: Wed, 27 Jun 2007 11:07:30 -0400

On 27 Jun, Michael Welzl wrote:

> of the ECN bits?

Umm, just what flags field are you asking about?  There are
three flags in the top bits of the fragment offset field,
but the rest of the field is the frag offset itself.

Yes, manipulating the ToS field (and having only 64 DSCPs)
is certainly a pain, but where else are you gonna grab a
pair of bits?

Dennis Rockwell          [email-masked]
Mobile Network Systems   Senior Engineer
BBN Technologies         +1-617-873-5745
Cambridge, MA            +1-617-873-5386 (Fax)

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Jun 2007 17:22:17 +0200

> but the rest of the field is the frag offset itself.

Yep, these three. They're depicted on page 11 of RFC 791. Again,
I would like to apologize if I'm just being stupid here - I'm
surprised that this wasn't updated by any other RFC, but then
again, I guess that the updating history that I get when I search
for 791 in the rfc editor's webpage and follow the links on the
right should point me there, and couldn't find any update...

> is certainly a pain, but where else are you gonna grab a

Well, let's start with one  :)   Page 13 of RFC 791 states:
"Bit 0: reserved, must be zero" (referring to this Flags field
that I'm talking about)

Cheers,
Michael

---

From: "Agarwal, Anil" <[email-masked]>
Date: Wed, 27 Jun 2007 11:30:05 -0400

All,

To my knowledge, ipv4 Flag bit 0 remains unused and reserved.
However, there is no corresponding bit in the ipv6 header, so the
solution will not apply to ipv6 :(

Anil

> > > This is probably a stupid question, and surely I'm 
> missing something 
> > > - but then again, this will make the question easy to answer:
> > > 
> > > Why don't use use bit 0 of the "Flags" field in the IPv4 header 
> > > instead of the ECN bits?
> > 
> > Umm, just what flags field are you asking about?  There are three 
> > flags in the top bits of the fragment offset field, but the rest of 
> > the field is the frag offset itself.
> 
> Yep, these three. They're depicted on page 11 of RFC 791. 
> Again, I would like to apologize if I'm just being stupid 
> here - I'm surprised that this wasn't updated by any other 
> RFC, but then again, I guess that the updating history that I 
> get when I search for 791 in the rfc editor's webpage and 
> follow the links on the right should point me there, and 
> couldn't find any update...
> 
> 
> > Yes, manipulating the ToS field (and having only 64 DSCPs) is 
> > certainly a pain, but where else are you gonna grab a pair of bits?
> 
> "Bit 0: reserved, must be zero" (referring to this Flags 
> field that I'm talking about)
> 
> Cheers,
> Michael
> 
> 
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 27 Jun 2007 17:48:59 +0200

> solution will not apply to ipv6 :(

But there, we have 20 stupid bits just to label a flow.
Convince me that 19 wouldn't be enough  :-)
(and that the benefit of having 20 as opposed to 19 is
greater than the benefit of re-ECN).

Cheers,
Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Jun 2007 18:05:19 +0100

Michael & all,

I use one extra bit along with the 2b ECN field to make a 3b field, giving 
8 codepoints. I get the extra bit from a different place depending on 
whether its IPv4 or IPv6.

In both cases, I avoid or overload the codepoints that 'legacy' ECN already 
uses. In all, this uses up 7 of the 8 codepoints. The only collision I 
coudln't avoid was with the nonce codepoint of ECN, which is why there was 
all the fuss over that.
See Table 1 in Section 3.2
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_Abstracted_Network_Layer_Wire_Protocol>

IPv4
----
AFAI can see, you're talking about the bit in the IPv4 header that I have 
already proposed to use for re-ECN (which I call bit 48). See Section 5.1:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_IPv4_Wire_Protocol>
(I've given it the tag RE for "re-ECN extension", which also matches it's 
old name "Reserved" :)

You'll find there's a bit of subtle half-serious British humour in the last 
para of that section :)

Unfortunately, there's no IETF process to reserve, experiment or assign the 
use of bit 48. See <http://www.ietf.org/rfc/rfc4727.txt>. When I asked Bill 
Fenner during the process of writing that RFC, he said he didn't want to 
add anything about bit 48, because he was merely bringing together the 
processes already documented elsewhere.

IPv6
----
In IPv6, I'm proposing to use an extension header. This uses some 64b just 
to get 1 extra bit, however, it gives us 31b spare. See Section 5.2:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-briscoe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_IPv6_Wire_Protocol>

Possible uses for 31 spare bits: I've half-written a paper 'proving' more 
bits than 1 per datagram will be needed to notify congestion for hi-speed 
congestion control. And I've just posted an I-D saying that we may need two 
ECN fields in the future for byte and packet congestion.
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#byte-pkt-mark>

Bob

---

From: "Michael Welzl" <[email-masked]>
Date: Wed, 27 Jun 2007 19:30:19 +0200

> coudln't avoid was with the nonce codepoint of ECN, which is why there was

Sure - that Nonce bit is the part that I hoped that could be changed  :)
(also because of my own Nonce based proposal which I'll be writing
a paper about these days ... I told you about that in London, remember?
see the (now finished) master thesis at
http://www.welzl.at/teaching/dipls/thomas-raffler.pdf
if you're interested)

> See Table 1 in Section 3.2
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-brisc
oe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_Abstracted_Network_Layer_Wire_Prot
ocol>
> already proposed to use for re-ECN (which I call bit 48). See Section 5.1:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-brisc
oe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_IPv4_Wire_Protocol>
> (I've given it the tag RE for "re-ECN extension", which also matches it's

Oh right, sorry for that! I missed this.

> You'll find there's a bit of subtle half-serious British humour in the
last

Indeed   :)    I read this "evil bit" RFC once and enjoyed it a lot, but
forgot which bit they took...

> processes already documented elsewhere.

Thanks for the pointer to RFC4727 - that's an interesting one!

> to get 1 extra bit, however, it gives us 31b spare. See Section 5.2:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/draft-brisc
oe-tsvwg-re-ecn-tcp-04b.html#retcp_Re-ECN_IPv6_Wire_Protocol>

makes sense

> congestion control. And I've just posted an I-D saying that we may need
two

Hm; that sounds like a pointless exercise, as you certainly won't be the
first to
make statements in this direction... there are several complete Ph.D. theses
out there (including my own) which make just that point...

What the heck, I'm sure there's more to it.

Cheers,
Michael

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 27 Jun 2007 18:59:45 +0100

M,

>http://www.welzl.at/teaching/dipls/thomas-raffler.pdf

I'll take a look - but not right now!

Bob

---

From: "Michael Welzl" <[email-masked]>
Date: Wed, 27 Jun 2007 21:43:52 +0200

> I'll take a look - but not right now!

thanks! but really, it's not that important anyway - being yet another
spurious timeout detection scheme, it's quite incremental and as
such not at all in the same league as re-ecn regarding the
potential benefits

cheers
michael

ps: if you're interested in a shorter, more readable version, you
could also decide to wait until we get the paper published which
i'm planning to turn this into over the next couple of days...