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

["Eggert, Lars" <[e-mail]>]

Hi,

On 2017-11-21, at 17:56, marcelo bagnulo braun <[e-mail]> wrote:
> El 21/11/17 a las 16:23, Eggert, Lars escribió:
>> 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?

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.

>> 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