Subject: [tcpm] Comments on draft-bagnulo-tcpm-esn

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 21 Nov 2017 15:23:35 +0000

Hi,

after my half-baked idea during the Singapore session (i.e., WS option 15 means "multiply by 64 or other large value), here's another one, even less baked:

Make WS option 15 mean "no flow control".

If you're doing >100G/s for a single flow, you're very unlikely to still rely on flow control to protect you from being overrun. Your problem is likely the exact opposite, i.e., making sure that there are no local bottlenecks that would prevent you from reaching that level of throughput. Plus, the number of slots in your NIC ring is probably already enforcing some sort of FC on you...

Lars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Nov 2017 17:56:06 +0100

Hi,

Reply below...

> after my half-baked idea during the Singapore session (i.e., WS option 15 means "multiply by 64 or other large value), here's another one, even less baked:

I understand what you are saying here is that the units to which a 
sequence number is assigned is no longer a byte, but a multiple of n 
bytes, e.g. 64 bytes.

I guess a first issue here is what happens if the amount of data that 
the sender wants to send in a segment is not multiple of 64 bytes (and 
it is not the last segment in the connection)?

The problem is which seq number you put to the next segment, since the 
first byte of data in the next segment was part of the previous segment 
64-byte word. Moreover, what happens if you want to send n packets of 
one single byte?

Regards, marcelo

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 22 Nov 2017 08:07:43 +0000

Hi,

On 2017-11-21, at 17:56, marcelo bagnulo braun <[email-masked]> wrote:
> I understand what you are saying here is that the units to which a sequence number is assigned is no longer a byte, but a multiple of n bytes, e.g. 64 bytes.
> 
> I guess a first issue here is what happens if the amount of data that the sender wants to send in a segment is not multiple of 64 bytes (and it is not the last segment in the connection)?
> 
> The problem is which seq number you put to the next segment, since the first byte of data in the next segment was part of the previous segment 64-byte word. Moreover, what happens if you want to send n packets of one single byte?

I said "half-baked" for a reason :-)

I'd observe that if you intent to go 100G on a single flow, you are unlikely to be successful if you are sending packets with less than 64B of data.

There are ugly ways to handle such corner cases, such as padding to 64B with dummy data and adding a new TCP option to remove that data from the byte stream delivered to applications.

Lars

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 22 Nov 2017 08:57:10 -0800

On Wed, Nov 22, 2017 at 12:07 AM, Eggert, Lars <[email-masked]> wrote:

> >> after my half-baked idea during the Singapore session (i.e., WS option
> 15 means "multiply by 64 or other large value), here's another one, even
> less baked:
> >
> sequence number is assigned is no longer a byte, but a multiple of n bytes,
> e.g. 64 bytes.
> >
> the sender wants to send in a segment is not multiple of 64 bytes (and it
> is not the last segment in the connection)?
> >
> 64-byte word. Moreover, what happens if you want to send n packets of one
> single byte?
>
> I'd observe that if you intent to go 100G on a single flow, you are
> unlikely to be successful if you are sending packets with less than 64B of
> data.
>
> There are ugly ways to handle such corner cases, such as padding to 64B
> with dummy data and adding a new TCP option to remove that data from the
> byte stream delivered to applications.
>
>
I would like to think about it a bit more, but this approach will
definitely require to investigate middlebox interventions as it looks
inconsistent retransmissions from them.
Some proxies that try to cache the segments might be confused by it.

BTW, I'm not sure how we do "no flow control".. Do we still use sliding
window?
--
Yoshi